Money Out Needs Two More Secrets
Collecting money from a customer and sending money to a supplier use the same provider account and are not the same capability. The outgoing side needs credentials the incoming side never asks for, and an organisation configured to collect is not yet configured to pay.
Our take
The most useful thing to understand about payment integrations is that providers deliberately make sending harder than receiving. Receiving money is low risk to everybody: the worst case is a payment you did not expect. Sending money is the operation an attacker wants, so the providers put it behind additional secrets — an initiating identity on the mobile rail, a created and verified recipient on the card rail. That asymmetry shows up directly in the configuration here, and the practical consequence is one that catches people at exactly the wrong moment: an organisation that has been taking payments happily for months is not thereby able to pay a supplier, and the discovery usually happens on the afternoon somebody needs to.
Taking money needs a key. Sending money needs a key and somebody to say who is sending it.
The same account, two directions
Both directions run on your organisation's own provider credentials. Nothing about paying a supplier passes through the platform's own configuration, exactly as nothing about collecting from a customer does. What differs is what the provider demands before it will move money away from you.
| Collecting | Paying | |
|---|---|---|
| Mobile money | Consumer key and secret | The same, plus an initiator identity and an initiator password |
| Card rail | Your secret key | The same key, different endpoints, and a recipient that must be created first |
| Where the money goes | Into your account | Out of it |
| What a wrong configuration costs | A refused collection at a till | A supplier who has not been paid |
The initiator is a person, not a key
On the mobile rail, the extra credential is an initiating identity with its own password — the provider's way of asking who, within your organisation, is authorising an outgoing payment. It is held encrypted at rest, and it is the single most common reason a supplier payment fails on a system that has been collecting successfully for months. Collection never asks for it, so it is never noticed missing until the first payout.
The card rail wants a recipient, not an account number
Paying a bank account through the card rail is a two-step arrangement: the destination has to be registered with the provider first, and the payment is then made to that registered destination rather than to a set of numbers.
The list of possible destinations is fetched from the provider for a currency and a country, and each entry says what kind of destination it is — a bank account, or a mobile money destination such as a wallet, a till or a paybill. That distinction matters because the two are set up differently, and a screen that treats them as one list produces a payment that fails at the provider rather than at the form.
Where the provider cannot be reached or the configuration is incomplete, the list comes back empty rather than as an error. So a payment screen with no destinations to choose from is usually a configuration problem or a connectivity problem, not an absence of banks.
An empty list of banks is a message about your configuration, not about banking.
One token, two purposes
A small detail worth knowing because it explains a class of intermittent behaviour. On the mobile rail, collection and disbursement share the same credentials, and therefore share the same cached access token — one token per organisation per environment, held for just under an hour.
That is efficient and it is correct, and it means a credential change affects both directions at the same moment. It also means that if the token cache is cleared for one purpose, the other picks up a fresh one on its next call. Nothing here is surprising, but it does explain why a mobile money problem is rarely a problem with one direction only.
What to check before you need to pay somebody
You have been collecting successfully for months
Do not assume you can pay
Collection credentials do not include what disbursement needs. Make a small test payment before the day you have to make a large one.
Your payment screen shows no destinations
Check the configuration before the bank list
An empty list means an incomplete configuration or an unreachable provider. It is almost never a real absence of destinations.
You pay both to bank accounts and to wallets
Confirm both destination types work
They are registered differently with the provider, so success with one says nothing about the other.
A supplier payment failed and you cannot see why
Look for the initiator credential first
It is the credential collection never uses, so it is the one most likely to be absent, expired or set for the wrong environment.
What happens after the money leaves
Worth naming because the outgoing side has one failure mode the incoming side does not. A payment can succeed at the provider and fail to be reflected against the order it was for — a callback processed while something else was failing, or a payment recorded outside the normal path. The money has gone and the order still shows a balance.
That is caught by an hourly sweep comparing each order's recorded payment total against the sum of its successful payments and correcting the difference. It never double-counts, because the correction sets the total from the payments rather than adding to it. It is the sort of safety net that exists precisely because the outgoing side has a step the incoming side does not: money that has already left cannot be retried.
Five questions to ask about supplier payments
Whose account does the money leave?
A good answer sounds like
Yours.
What ours actually is
Yours. Disbursement uses your organisation's own credentials and never the platform's.
Does paying need more than collecting?
A good answer sounds like
Yes, and what.
What ours actually is
Yes — an initiating identity and password on the mobile rail, and a registered recipient on the card rail.
Where is the initiator password held?
A good answer sounds like
Encrypted.
What ours actually is
Encrypted at rest on the organisation's own configuration record.
What if a payment succeeds but the order does not update?
A good answer sounds like
A reconciliation.
What ours actually is
An hourly sweep compares each order against its successful payments and corrects the difference, setting the total rather than adding to it.
Can I pay a wallet as well as a bank account?
A good answer sounds like
Yes, with the difference named.
What ours actually is
Yes. The provider's destination list distinguishes bank accounts from mobile money destinations, and the two are registered differently.
Making a payout configuration verifiable
The rails work and the credentials are held correctly. What organisations ask for is the ability to find out that a payout configuration is complete before a supplier is waiting on it.
A configuration test
A check confirming the disbursement credentials authenticate, run on demand and on a schedule, so an absent initiator identity is found before payday.
A payout run
Several supplier payments prepared, approved and released together, rather than one at a time.
A settlement reconciliation
The provider's own payout report matched against the payments that produced it, so the bank statement and the ledger meet without retyping.
We publish scope, not dates.
Scope supplier paymentsWhat AWRA OpsHub does today
- Supplier payment on your organisation's own provider credentials, out of your own account, never touching the platform's configuration.
- An initiating identity and password required for mobile money disbursement, held encrypted at rest and separate from the credentials collection uses.
- Card-rail transfers on the same secret key as collection against different endpoints, with amounts submitted in the currency's smallest unit.
- A destination list fetched from the provider per currency and country, distinguishing bank accounts from mobile money destinations so the two can be registered differently.
- An empty destination list rather than an error when the configuration is incomplete or the provider is unreachable, so a payment screen fails cleanly.
- A shared access token between collection and disbursement on the mobile rail, cached per organisation and environment for just under an hour.
- One gate that every payment path calls before money is released, so a supplier payment cannot bypass the matching checks by choosing a different route.
- An hourly sweep correcting any order whose recorded payment total disagrees with the sum of its successful payments, setting the figure rather than adding to it.
More we can add to your workspace
- A configuration test for disbursement credentials, confirming they authenticate before a supplier is waiting on a payment.
- A payout run, preparing, approving and releasing several supplier payments together rather than one at a time.
- A settlement reconciliation matching the provider's payout report against the payments that produced it.
- A retry with a fresh token on an authentication failure, so an expired token surfaces as a delay rather than as a failed payment.
- Disbursement in currencies beyond the one these rails are wired for, handling each provider's supported list and smallest-unit rule together.
- A dashboard of payments initiated, completed and failed per rail, so an intermittent problem is visible as a rate rather than as individual complaints.
Where we point you to a specialist
- We will not hold the credentials that authorise money leaving your account anywhere but in your own configuration. An initiating identity is the provider asking who in your organisation authorised a payment, and the honest answer has to be somebody in your organisation.
- Enabling disbursement on a provider account, and whatever verification that requires, is between you and your provider. We will tell you which credentials the integration needs and where they go; the onboarding is theirs and it varies by market and by account.
- We will not retry a payment that may have succeeded. Money already sent cannot be unsent, and a retry that turns an ambiguous response into a second transfer is a worse failure than a payment somebody has to check by hand.
A configuration test is the highest-value small piece here, because the failure it prevents is entirely a timing problem — the credential sits unset all along and is only discovered when somebody urgently needs to pay.
Make a small payment before you need to make a large one
The disbursement credentials are the ones collection never exercises, so they are the ones nobody discovers are missing. A test payment of a few shillings answers it in five minutes.
Talk through supplier paymentsFrequently asked questions
We can take payments. Why can we not send them?
Because the provider asks for more before money leaves your account. On the mobile rail that is an initiating identity and its password, which collection never uses; on the card rail it is a registered recipient rather than a set of account numbers. An organisation configured for collection is genuinely not yet configured for disbursement, and the two are worth setting up at the same time.
Where is the initiator password stored?
Encrypted at rest on your organisation's own payment configuration, alongside the other credentials for that rail. It is never held by the platform for its own purposes — the platform's subscription billing runs on entirely separate configuration that these paths never touch.
Why does my payment screen show no banks?
Almost always an incomplete configuration or an unreachable provider. The destination list is fetched live and comes back empty rather than as an error in both of those cases, which keeps the screen from breaking but does make the cause less obvious. Check the credentials before concluding the list is genuinely empty.
Is paying a mobile wallet the same as paying a bank account?
Not to the provider. The destination list marks each entry as a bank account or a mobile money destination, and the two are registered differently before a payment can be made. Success with one tells you nothing about the other, which is worth knowing if you pay some suppliers to accounts and others to wallets.
What happens if a payment succeeds and the order does not update?
An hourly sweep compares each order's recorded payment total against the sum of its successful payments and corrects any difference, setting the figure from the payments rather than adding to it. It exists because the outgoing side has a failure the incoming side does not: money that has already left cannot be retried, so the record has to be brought to the money.
Can we pay several suppliers at once?
One at a time today. A payout run — several payments prepared, approved and released together — is on the list above and is the request that comes up as soon as an organisation moves from occasional supplier payments to a regular payment day.
