Seev PlusDocs
Docs
Get Paid

Get Paid with Seev Plus

Set the organization up, pick the right way to request a payment, and know what to do at each status before you fulfil.

Seev Plus runs your payment and commerce workflows from one business workspace. You can issue invoices and payment links, sell through a storefront or a POS screen, hold balances in wallets, and put payments inside your own product through the Seev API. This page walks the setup in the order it has to happen, then covers what to do once money starts arriving.

About 20 minutesVerification approval can take up to a business day

If your custom integration still initializes or verifies payments through gateway-api.seevcash.com, migrate to the SeevPlus payment routes. The new routes preserve the gateway request and response contracts while adding the organization context needed for reliable transaction attribution, wallet processing, alerts, and internal tracking. Read the migration guide.

Create your organization

An organization is the business workspace that owns everything you create: stores, invoices, customers, wallets, API keys, verification state, and team access. One login can belong to several organizations, and their records never mix.

After signing in for the first time, enter a business name, create the organization, then confirm it in the selector at the bottom of the sidebar.

Check the active organization before you create a record or move money. A payment link made in the wrong workspace settles into the wrong wallet. See Organizations for switching and roles.

Complete organization verification

You can explore and prepare most of the product before approval. Accepting live payments, using production API access, and some payout actions all wait on approved verification, so start this early rather than on launch day.

Individual or contractor

Freelancers, creators, and sole operators with no company registration documents.

Registered business

Incorporated companies with business and ownership documents.

The dashboard reports whether verification is not started, in draft, ready for review, approved, or rejected. See verification for what each document has to show and what approval unlocks.

Choose how to get paid

Every option below ends at the same hosted checkout, so the payer's experience is the same whichever you choose. What differs is where the request starts and how much structure it carries. Take the least complicated one that fits the sale.

The customer needs line items, tax, discount, terms, or a due date.

A recipient, an amount, and a short description are all you need.

Customers should browse products and build their own cart.

A walk-in customer whose products you select on their behalf.

Your own app or website creates the payment.

Part of each payment belongs to a partner, branch or vendor and should settle to them directly.

API amounts use the currency’s smallest unit, so 10000 means GHS 100.00.

The dashboard tools need no code. The Checkout API needs developer terms, a product-specific key, server-side code, payment verification, and webhook handling, so choose it when your application has to own the flow rather than because it sounds more capable.

Creating an invoice, link, or store is not the same as being able to accept payment. Without approved verification, Seev lets you prepare the item and blocks generation of a live checkout link.

Find where funds land

Successful payments settle to the active organization's accounts. Open Balances to see the GHS wallet, the stablecoin wallet, transaction history, and any virtual account available to the organization.

The currency picker changes which wallet you are looking at. It does not convert one balance into another, and a GHS balance and a USDC balance remain separate funds.

Payments made through an invoice, a payment link, a store order, a POS order and the API can appear in different operational tables, but the funds belong to the organization that created the payment in every case. If a payment landed under an organization you did not expect, check which one was active at creation, and read the migration guide if the payment came from a direct gateway integration.

Set a transaction PIN

Each organization has its own four-digit transaction PIN, and Seev asks you to set it before the first sensitive action such as a withdrawal, a transfer, a card action, or a yield movement. Digits stay hidden while you type.

The PIN is yours and not the team's, so do not share it with teammates. See PIN guidance.

Configure payouts

Settled funds go out on a schedule of every business day, weekly, or monthly. Add a payout destination before the first payout can run, because a schedule with no destination has nowhere to send to. Manual payouts are no longer offered. See payout settings.

Check before your first live payment
Tick these off and the payment will go where you expect.
  • The correct organization is selected.
  • Organization verification is approved.
  • The customer, amount, currency, and description are right.

  • Invoice line items are complete, if you are using an invoice.

  • Store products are active, in stock, and carry an image.

  • The checkout link opens for you before you share it.
  • The completed payment appears in its own record and in the Balances activity feed.

Know what the customer sees

The customer opens a Seev-hosted checkout page showing your business, the amount, the purchase details and the payment methods currently available for that payment. After they pay, Seev verifies the result and updates the source invoice, link, order or API transaction. For a POS order, the payer can supply an email for their receipt without you creating a full customer profile first.

Available methods are decided per payment rather than per tool, so read Payment Methods before telling a customer how to pay.

Follow a payment status

StatusWhat to do
DraftFinish preparing the request before sharing it.
Active / SentThe request is ready for the customer.
PendingWait for a final confirmation; do not immediately ask the customer to pay again.
Paid / CompletedThe payment succeeded. Continue fulfilment and retain the receipt record.
FailedRead the reason and let the customer retry when appropriate.
ExpiredThe checkout can no longer accept payment. Create a new request if money is still due.
CancelledThe merchant intentionally stopped the request. It cannot be paid.

Avoid charging a customer twice

A pending payment can still complete. Creating a replacement while the first attempt is live is how a customer ends up paying twice, and a mobile money charge is not something you can quietly undo. Before you create a replacement checkout, refresh the original record, check its current status, search the reference in transaction activity, and confirm the customer was not already charged.

Paid records deliberately remove the copy, QR and checkout-generation actions for the same reason. If those controls are still visible on a record you believe was paid, you are looking at a stale page. Refresh it.

On this page