Skip to main content
Who this is for: Developers building for a shop, an online store, or a business that sells through both. Includes teams connecting a POS terminal to an ERP or retail management system. Retail is the vertical most likely to need two payment channels at once — a website and a physical till — reconciled into one set of books. This page walks the three integrations that cover it, in the order most teams build them.

Online store checkout

Take payment on your website or app.

In-store on a terminal

Push a sale from your till or ERP to a POS terminal.

One view across both

Reconcile online and in-store into one ledger.

​
Online store checkout

What you’re building: A customer fills a cart on your store and pays. You need the order marked paid only when the money is genuinely collected.

​
The flow

1

Create the transaction on your server

Call Standard Checkout with the cart total and a paymentReference you generate. You get back a redirectLink.If you would rather the customer never leaves your page, use Simple Checkout instead — same result, an overlay rather than a redirect.
2

Send the customer to pay

Redirect to the redirectLink. The customer pays with any method enabled on your account — card, transfer, USSD or mobile money.
3

Confirm before you fulfil

Do not mark the order paid on the browser redirect. Either receive the webhook or verify the payment — then check the amount and currency match the order before releasing stock.

​
Decisions specific to retail

  • Tie paymentReference to your order number. Use your own order ID with a prefix, e.g. ORD-20260904-0041. It is what you will reconcile on, and it must be unique per attempt.
  • Offer more than cards. Cart abandonment in these markets is often a payment-method problem, not a pricing one. Transfer and USSD reach customers a card-only checkout loses.
  • Selling for other sellers? If your store settles money to third parties, use split settlement so each seller is paid directly rather than you paying them afterwards.

​
What to watch

Partial approvals. A card issuer can approve less than you charged (SM_10). Compare payments.amount against your order total on every verification — a successful payment for the wrong amount is still the wrong amount. Abandoned tabs. Customers close the browser after paying more often than you would expect. Webhooks catch those; a redirect-only integration loses them.

​
In-store on a terminal

What you’re building: A sale rung up in your till, ERP or retail management system, pushed to a SeerBit POS terminal for the customer to pay — with the result posted back automatically so nobody re-keys it.

​
The flow

1

Send the sale to the terminal

Call initiate transaction with the terminal’s posid, the amount, and your own orderId. The payment request appears on the terminal.
2

Wait for the customer to pay

Either poll transaction status with that orderId, or supply a webhookUrl at initiation and let SeerBit notify you the moment it resolves.
3

Post the result back into your system

On COMPLETED, mark the sale paid against the same orderId you sent. The response carries amountPaid, the masked card and the sessionId for reconciliation.

This API is authenticated differently

In-store calls use a PublicKey header and a request signature — not the bearer token used by the online APIs.

​
Decisions specific to retail

  • Use your ERP’s document number as orderId. It is the path parameter for every status query, so making it your own invoice or sale number removes a mapping table.
  • Prefer the webhook over polling. A queue at the till is the worst place to be waiting on a polling interval.
  • sessionId is SeerBit’s reference for the transaction. Store it alongside your sale — it is what SeerBit support and your settlement report will reference.

​
What to watch

A terminal must be linked to your account. A posid that is not assigned returns 403 TERMINAL_NOT_ASSIGNED — worth surfacing clearly in your till software rather than as a generic failure. The customer can walk away. A transaction stays OPEN until the terminal resolves it. Decide what your till does with an unresolved sale before you ship.

​
One view across both channels

What you’re building: Online and in-store sales landing in one ledger, reconciled the same way, without a nightly export. Both channels emit webhooks and both carry references you control, so the work is mostly choosing consistent identifiers up front.

​
Decisions specific to retail

  • Use one reference scheme across both channels, with a channel marker — WEB-20260904-0041 and POS-20260904-0042. One scheme means one reconciliation routine.
  • Store SeerBit’s reference too. linkingReference and sessionId are what support and settlement reports use; your own reference will not be enough in a dispute.
  • Handle both webhook systems. They are separate: online webhooks require an acknowledgment body, in-store webhooks do not, and the headers and payloads differ. Build two handlers, not one.

​
Selling repeat customers a membership

For loyalty tiers or subscription boxes, charge the card again without re-collecting it: Either way, set tokenize: true on the first checkout and retrieve the authorizationCode from the payment status — that avoids handling card details yourself, so no PCI DSS certification is required.

​
Before you go live

Test both channels

Test cards, and how test and live modes differ.

Go live

KYC, swapping keys, and re-pointing webhooks per channel.
Webhook URLs are configured per mode and per channel. Going live means setting production URLs for your online and in-store webhooks — missing one is the most common day-one failure.