Troubleshooting Seev Plus
Diagnose and fix organization, verification, payment, storefront, wallet, and API failures in Seev Plus.
Most Seev Plus failures trace back to the active organization, the verification state, the status of the record you are acting on, or a prerequisite that has not been met. Work through the section that matches what you are seeing before you retry the action or recreate the record.
Run these checks first
- Confirm the organization shown at the bottom of the sidebar.
- Refresh the page after changing organizations.
- Check the verification banner and follow its action if one is shown.
- Confirm the record is still active and has not been paid, cancelled, or expired.
- Check that the currency and source wallet match the action.
Fix wrong business data
Open the organization selector and choose the correct organization. Stores, customers, invoices, payment links, wallets, verification, API keys, and PINs are scoped per organization and do not carry over between them, so a record created under one organization is invisible from another.
If the correct organization is already selected, refresh the page once. Do not recreate a record until you have confirmed it is genuinely missing, because recreating it under the wrong organization is what usually turns one missing record into two.
Generate a checkout link
Live invoice and payment-link checkout requires approved organization verification. If verification is not yet approved, resolve that first using the section below.
Once verification is approved, confirm each of the following:
- The invoice has a customer and at least one item.
- The invoice or payment link is not paid or cancelled.
- An earlier checkout link has not already completed payment.
- The amount is greater than zero and uses a supported currency.
Clear a blocked or rejected verification
Act according to the state shown on the verification banner.
- Draft: Continue the remaining modules shown by the verification app.
- Ready for review: No action is required unless Seev requests a change.
- Rejected: Read the reason in the Dashboard banner, choose Update verification, edit the existing prefilled information, and submit again.
- Approved: Refresh Seev Plus if a restricted action does not unlock immediately.
Use the business or contractor email associated with the verification profile. One active verification profile cannot be shared across unrelated emails, so signing in with a different address starts a separate profile rather than continuing the existing one.
Enable a storefront product
A public storefront product needs at least one image. Click or drop an image onto the empty thumbnail, wait for the upload to finish, then enable the product. Enabling before the upload completes leaves the product in its previous state.
Also confirm the product is active and has available stock. Disabled products do not appear in POS or in the public store.
Resolve a payment link with no copy or QR action
Copy, QR, and active checkout actions disappear once a link is paid, cancelled, expired, or otherwise no longer payable. The link may still be visible as a receipt record, which is why it looks present but inert.
Create a new payment request only when the underlying sale genuinely needs another payment. A second link against an already-paid sale is a double charge waiting to happen.
Resolve a pending payment
Pending means Seev has not received a final result yet. It does not mean the payment failed, so do not ask the customer to pay again immediately.
- Wait for the customer's mobile-money or payment confirmation.
- Refresh the transaction or the source record.
- Check whether a final status or webhook event has arrived.
- Use the payment reference when comparing Dashboard records against customer records.
If you are integrating over the API, verify the session server-side rather than waiting on the webhook alone. Automatic webhook delivery is a single attempt with no automatic redelivery, so a pending record can stay pending in your own database purely because one delivery failed. See Work around single-attempt delivery.
Reconcile a balance that looks wrong
GHS, USDC, and other wallet balances are held separately. Changing the currency view switches which balance you are looking at; it does not convert or merge them.
Confirm the selected organization, the selected wallet, the transaction status, and the currency before treating the number as wrong. A pending payment may be counted in the record but not yet available to withdraw, which accounts for most reported mismatches.
Fix a transaction PIN that will not verify
PINs belong to organizations. A PIN set on another organization will not verify here, so confirm the active organization and use the PIN that belongs to it.
Avoid repeated guesses. If the current PIN cannot be verified, use the available recovery path rather than creating another organization or another PIN, both of which leave you with more state to reconcile and do not restore access.
If the PIN cannot be recovered, contact support. After you verify your identity against the organization, support resets the PIN to a placeholder for you to change from the dashboard. See PIN guidance.
Save a payout schedule
Manual payouts do not require a destination. Scheduled payouts require both a valid selected destination and approved verification, so a schedule that will not save usually has one of those missing.
Check that the destination details belong to the active organization and match its destination type.
Fix a failing API request
Confirm all of the following before changing your request body:
- Developer terms have been accepted for the organization.
- The key belongs to the correct product, which is Checkout API for checkout requests.
- The key and the Dashboard are using the same sandbox or production environment.
- Production verification is approved.
- The secret key was copied when it was first shown and has not been rotated or deleted.
- The request body and URL match the current Checkout API guide.
Amounts are a common cause of a rejected body. They are expressed in the currency's smallest unit, so 10000 with currency GHS means GHS 100.00, and sending 100 for that same charge requests GHS 1.00.
A key issued before the SeevPlus payment routes existed must be rotated once before it can authenticate against them, because only a one-way hash of newly issued secrets is stored. That failure returns 401 with a message ending existing keys must be rotated once before using this endpoint.
Read the HTTP status together with the response body, then look the status up in Errors, which lists what each one means per route and whether it is safe to retry. Note that an inactive organization returns 400 rather than 403, so a 400 is not always a malformed body.
When you share a failure with support or a colleague, include the HTTP status, the response body, the transaction reference, and the Idempotency-Key you sent. Never share a secret key or a full customer payment payload.