Protected checkout
Protected checkout for buyers and merchants
ArosaPay records and safeguards payment against a transaction before settlement is released. The merchant fulfils, the buyer confirms the agreed outcome, and release follows the transaction's release condition. If a problem is reported, release pauses while the transaction moves through review.
What a protected transaction looks like
Illustrative example. The figures, merchant and reference below are made up for explanation — they do not describe a real transaction.
KES 24,500
Payment safeguarded
- Merchant
- Sahara Electronics
- Merchant reference
- ORD-20481
- Release condition
- Buyer confirmation
- Current state
- Awaiting merchant fulfillment
Lifecycle
- 01 Payment safeguarded
- 02 Merchant fulfils
- 03 Buyer reviews
- 04 Release pending
- 05 Settlement released
Exception: a reported problem moves the transaction to under review and release pauses.
What the buyer sees
The buyer always sees the amount, the merchant, what was bought, the release condition, the current state, and the one action available next.
KES 85,000
Ready for your review
- Payment
- Safeguarded
- Release condition
- Buyer confirmation
- Next action
- Confirm or report
- I received it
- Report an issue
Confirming releases the transaction towards settlement, so a buyer should confirm only after receiving the order as agreed.
Reporting an issue does the opposite: the transaction moves into review before release, and evidence may be requested from both sides.
What buyer protection covers explains the buyer side in more detail.
What the merchant sees
A merchant should never dispatch against a screenshot or a frontend message. The transaction state is the authoritative answer to whether payment has been safeguarded.
KES 85,000
Funds safeguarded — ready for fulfillment
- Release condition
- Buyer confirmation
- After fulfillment
- Awaiting buyer confirmation
- Then
- Release pending
- Finally
- Settlement released
Every state change is delivered to the merchant's own system as a signed webhook event, so the merchant dashboard and the merchant's order system agree on one state.
Merchant payment protection covers the operational side: what to do at each state, and what to do when the normal flow stops.
The transaction lifecycle
Five states in the normal path, one exception state. Each is written to the transaction record.
- 01Payment safeguarded
The buyer pays through ArosaPay and the payment is captured and recorded against the transaction rather than paid straight to the merchant's operating account.
- 02Merchant fulfils
The merchant dispatches or delivers, knowing the payment state rather than guessing at it. The release condition is already recorded on the transaction.
- 03Buyer reviews
The buyer checks the order against what was agreed and either confirms or reports a problem. Only these two actions move the transaction forward.
- 04Release pending
The release condition has been met and the transaction is moving to settlement. Settlement is not final at this point.
- 05Settlement released
Funds settle to the merchant payout account in line with the merchant agreement, and the transaction carries a settlement reference for reconciliation.
How protected checkout works end to end walks through the same lifecycle with the payment methods and timings.
What happens if something goes wrong?
A reported problem is a normal path, not a failure of the system.
Reporting is available from the transaction itself while the release condition is outstanding.
Release pauses. Neither side can move the transaction forward on their own while review is open.
Both sides may be asked for evidence — delivery records, photographs, correspondence, or the order agreement.
The review outcome may be release, refund, or partial resolution, according to the transaction and the evidence reviewed.
The dispute process in detail and dispute resolution describe how a review is run.
Protected checkout questions
What is protected checkout?
Protected checkout is a payment flow in which the buyer's payment is recorded and safeguarded against a transaction before the merchant is settled. The merchant fulfils, the buyer confirms the agreed outcome, and settlement is released according to the release condition recorded on the transaction.
When should the merchant fulfill?
When the transaction state shows that payment has been safeguarded. That state is set by ArosaPay from the payment record itself, not by a message, a screenshot, or a buyer's assurance.
When is settlement released?
After the release condition recorded on the transaction is met — typically buyer confirmation that the order arrived as agreed. The transaction then moves to release pending and, once settlement completes, to settlement released.
What happens if the buyer reports a problem?
Release pauses and the transaction moves to under review. Evidence may be requested from both sides. The review outcome determines whether the transaction ends in release, refund, or partial resolution.
Can the merchant see that payment has been safeguarded?
Yes. The transaction record shows the current state, the amount, the merchant reference and the release condition, and the same states are delivered to the merchant's own system through signed webhook events.
How is protected checkout different from paying the seller directly?
Paying directly settles the seller immediately and leaves the buyer with no recorded release condition. In protected checkout the payment is safeguarded first, both sides see the same transaction state, and settlement follows the agreed condition rather than the payment itself.
For merchants
Selling online? Start with the payment state.
Merchant payment protection explains how to use payment state and release conditions in day-to-day operations, and how to reconcile once a transaction settles.
Merchant payment protection