Important: Migrate to the SeevPlus Payment Routes

If your integration initializes or verifies payments through gateway-api.seevcash.com, move it to api.seevplus.com. The new routes preserve the gateway request and response contracts, so the change is normally two URLs and nothing else.

The reason to make it is attribution. A direct gateway call carries no organization context, so SeevPlus has to infer which organization a payment belongs to, and the fallback it uses is whichever organization was most recently selected. On an account that manages one organization you may never notice. On an account that manages several, payments land under the wrong one, and the transaction records, balances, alerts and receipts follow them there.

What changes and what does not

SeevPlus does not touch your checkout amount or your item calculations. The payment gateway still calculates totals and runs checkout, and the response comes back to you unchanged. SeevPlus adds the organization context around it and records its own transaction from the gateway's answer.

Before:

const response = await fetch(
    'https://gateway-api.seevcash.com/api/v1/payments/initiate',
    options,
);

After:

const response = await fetch(
    'https://api.seevplus.com/api/v1/developer/payments',
    options,
);

Keep the existing POST body, the existing checkout API key, and your existing response parsing including data.checkout_url. Keep your amount and item calculations exactly as they are: the smallest-unit convention is unchanged, so a value of 10000 still means GHS 100.00 on both routes. Do not start adding SeevPlus organization metadata by hand, because SeevPlus writes it from the authenticated key.

Two behaviours that differ from the old route

Your meta object is no longer passed through untouched. SeevPlus overwrites the keys organizationId, user_id, seev_origin and seev_environment with values derived from the API key, and preserves every other key you send. If your integration currently sets any of those four names for its own purposes, rename them before you migrate or you will lose the values silently.

A checkout key issued before this route existed cannot authenticate against it, because SeevPlus stores only a one-way hash of newly issued secrets and has no hash on file for an older key. Rotate the key once in the Developer Dashboard and deploy the new secret as part of the migration. Until you do, initiation fails with HTTP 401 and the message invalid API key; existing keys must be rotated once before using this endpoint.

The full request shape, the parameter table and the complete error list are on the Checkout API page.

Migration checklist

• Rotate the checkout API key once, and deploy the new secret.
• Rename any meta keys called organizationId, user_id, seev_origin or seev_environment.
• Replace the payment initialization URL.
• Replace the session verification URL.
• Confirm the checkout API key is still sent on the POST.
• Confirm the POST body is otherwise unchanged.
• Confirm redirects still use data.checkout_url.
• Confirm server-side verification uses the new GET route.
• Test amount-based checkout.
• Test itemized checkout.
• Test a failed payment as well as a successful one.
• Confirm successful payments appear under the correct organization.
• Confirm successful-payment alerts reach the correct recipient.

Related docs

• Checkout API
• Verify Payments
• Developer API Keys