Merchants
Merchants → Merchants is every account on the platform. It is the page you arrive at from almost every other queue, because most questions resolve to “what is going on with this merchant”.
The merchant file
Section titled “The merchant file”One merchant’s page gathers what is otherwise scattered: their verification status and documents, their capabilities and channels, their limits, their pricing, their settlement destination, their API keys and webhook endpoints, their transaction history, and their disputes.
Read the whole file before acting on any one part of it. A merchant asking for a limit raise looks different depending on whether their dispute rate is rising, and a merchant whose webhooks have been failing for a week looks different from one whose integration has never worked.
Status, and what each one does
Section titled “Status, and what each one does”| Status | Effect |
|---|---|
| Not live | Live requests refused with merchant_not_live. Sandbox still works. |
| KYC outstanding | Live requests refused with kyc_required. |
| Active | Normal operation. |
| Suspended | Live requests refused with merchant_suspended. |
Suspending stops collections. It does not freeze money already held. Those are separate decisions and they have separate consequences — a suspended merchant who can still withdraw is a different situation from one who cannot, and you should know which one you have created.
Suspension is visible to the merchant immediately, as failed payments. Before you suspend, know who is telling them and what they are being told. A merchant who discovers a suspension from their customers rather than from us will escalate, and they will be right to.
Capabilities and channels
Section titled “Capabilities and channels”Which payment methods a merchant may use. A disabled channel returns
capability_disabled rather than failing obscurely, so a merchant whose card
payments are refused while mobile money works is usually looking at this rather than
at a bug.
Card typically requires additional verification, because the scheme rules are stricter than the wallet rules. Enabling it is not a toggle to flip on request.
Finding a transaction
Section titled “Finding a transaction”Merchants → Transactions searches across the platform by reference. It is the
page to use when somebody gives you a PSG-… reference or a merchant’s own
reference and you do not yet know whose it is.
Two things about searching here:
Narrow the date first. The transaction table is partitioned by date, so a search without a window reads every partition. Narrowing the dates is what makes a slow search fast — this is not a hint, it is how the storage works.
Know which identifier you have. The PaySigna reference (PSG-…) is ours, the
merchant’s own reference is theirs, and the transaction id (txn_…) is what the API
uses. A merchant quoting “their reference” means the second one.
Before you change anything on a merchant
Section titled “Before you change anything on a merchant”Several things on this page are dual controlled, and several more are audited against you by name. For the ones that are neither, apply the same test anyway:
- Would you be comfortable explaining this change in six months, to someone reading only the audit entry?
- Does the merchant know it is happening?
- Is it reversible?
Write the reason into the record. “Requested by the merchant” is not a reason; it is a source. The reason is why the request was granted.