How a payment moves.
Six stages, the same for a payment link, a payout and a transfer.
From an app or API call, with an idempotency key.
Limits, approvals, verification status, sanctions checks.
Method and settlement route chosen from country capability data.
Sent to the processor or bank partner.
Partner webhook confirms or fails the payment.
Records written; your webhook fires.
Each stage, in plain terms.
Initiate
A payment starts in the app, in a payment link, from a QR scan or in a call to the API. Every request carries an idempotency key. If a connection drops and the request is sent again, Olympus recognises the key and returns the first result instead of paying twice.
Validate
Before anything moves, Olympus checks the sender’s limits, whether approvals are needed, whether the account is verified and whether the names involved trip a sanctions screen. A payment that fails a check stops here, and nothing is recorded.
Route
The country and the method decide the route: a card processor, a mobile-money network, a bank transfer or a local rail. These rules are held as data for each country, which is why opening a new market takes configuration and an integration, not a rebuild.
Execute
The payment is sent to the processor or bank partner. From this point it is in processing, and it stays there until the partner answers.
Confirm
The partner confirms the payment or reports that it failed, usually by webhook. Olympus acts on that answer and not on its own expectation.
Post
The result is written to the records, the balance follows, and your webhook fires. If the payment failed, it is marked failed, nothing is recorded against the balance and a payment.failed event tells your system.
Routing.
Which methods a merchant can use, which tax logic applies and where proceeds settle are read per country. A new market needs configuration and an integration, not a rebuild. A route that has not been tested end to end stays disabled behind a flag until it has been.
- Per-country capability data
- Settlement to an Olympus account or an external bank
- Unverified routes fail closed
Looked up in capability data.
Chosen from what that country allows.
Olympus account or external bank.
Methods, and how they differ.
Olympus supports card payments, mobile money and bank transfer, as well as payment links, QR codes, checkout, bulk payments and payouts. Which of these a merchant can use depends on the country, because each has its own rails, rules and tax treatment.
Behind a single payment link there can be several routes. A customer in one country pays by card, a customer in another pays with mobile money, and both payments settle to the same merchant account with the same record.
Read Payments for what a business can do with each method, and Merchant Services for acceptance and settlement.
Where the money settles.
Proceeds settle to an Olympus account or, where the merchant prefers, to an external bank. The settlement route is part of the same capability data as the payment method, so it is known before the first payment is taken.
For payments to other countries, the sender sees the rate and the fee before confirming. The sender pays the fee and the recipient receives the exact amount. Some markets are released the same day and others, on the higher-risk list, at T+1 after enhanced screening. The corridors page shows each rail, cut-off time and settlement time.
Partner integrations.
Olympus does not move money on its own rails alone: it connects to processors, settlement services and banking partners, and reflects each one’s status.
Card and mobile-money processing
Through a payments aggregator for card, mobile money and bank transfer.
Cross-border and FX
Through a settlement integration for international transfers and foreign-currency account details.
Records and bank sync
Through an accounting and bank-connection integration.
When something fails.
A request is retried
The idempotency key returns the original result.
A partner is slow
The payment stays in processing until a confirming webhook arrives.
A payment fails
Marked failed, nothing recorded, and a payment.failed event fires.
A large refund is requested
It waits for a second reviewer instead of executing.
Refunds, disputes and holds.
A refund is a payment in the other direction and goes through the same checks. A large refund waits for a second reviewer instead of running on its own, which protects the merchant from a mistake or from someone with access they should not use.
Where fraud or financial crime is suspected, Olympus can place a hold on funds or on a transaction. A person reviews the case and decides to release, ask for more information or escalate. Nothing is blocked silently and nothing is approved automatically.
What your software sees.
Every state change can reach your server as a signed webhook. Signatures use HMAC-SHA256 and carry a timestamp, so a message that has been replayed later can be rejected. Requests to the API are rate-limited per user, and when you exceed a limit the response is 429 with a Retry-After header telling you when to try again.
Sandbox and live keys are separate, scopes limit what a key can do, and keys are hashed at rest and shown once. The API reference has the details.
Payment infrastructure questions
What happens if a payment request is sent twice?
If both carry the same idempotency key, Olympus returns the result of the first and does not create a second payment.
Why does a payment stay in processing?
Because Olympus waits for the processor or bank to confirm it. Payments over some rails take seconds and others can take until the end of the day.
What happens when a payment fails?
It is marked failed and nothing is recorded against the balance. A payment.failed event is sent so your system can react.
Can I send to any country?
No. Olympus does not process transactions with some countries, and some corridors are still to open. The corridors page shows where you can send today.