Choosing a payment gateway for a marketplace with split payments and deposits

I have built deposit-based commerce: the pattern where a customer pays for a booking or a rental, an additional amount is held against damage or no-show, and part of it comes back later. It looks like a small variation on checkout. It is not. It is a different problem class, and if you choose your gateway on the assumption that it is a store with extra steps, you will find out around month four.

This is what to evaluate, in the order the decisions actually bite.

Three problems a normal store does not have

1. The money is not yours

When a customer pays 1,000 EGP for a booking, perhaps 850 belongs to the provider and 150 is your commission. Between capture and payout, you are holding somebody else's money. That is an accounting problem, a trust problem, and, depending on how you structure it, a regulatory one.

2. The amount is not final

Deposits are the awkward part. You take 500 EGP against damage; two weeks later you return 500, or 300, or nothing, and the decision is made by a human after a dispute. Payment systems are built around transactions that settle to a known amount. Yours does not.

3. Payouts must reconcile, forever

Every provider will eventually ask why a payout was a specific amount, and you need to answer with a breakdown: which bookings, what commission, which refunds, which deposit deductions, which adjustment from last month. If you cannot produce that on demand, you will lose providers, and you will not know how much money you have.

Ask the licensing question first

The practical consequence for architecture: the more the licensed gateway holds and moves the money, the less exposure you carry. Using a provider's marketplace product, where funds route into sub-merchant accounts the provider controls and the provider pays them out, keeps the regulated activity where the licence already is. Taking everything into your own account and paying providers by bank transfer from your balance puts you closer to the perimeter.

That single consideration will often decide your gateway for you, regardless of fees.

Split at capture, or split at payout?

There are two architectures and the choice cascades into everything else.

There is a third pattern worth knowing: hybrid. Split the core transaction at capture so revenue routes correctly, but keep the deposit in your own account as an explicit liability you control. It gives you the regulatory posture of the first model and the deposit flexibility of the second. It also means two reconciliation surfaces instead of one, so only do it if deposits are central to your product.

Deposits: hold or charge?

This is the decision people get wrong most often, so here it is in full.

Option A: pre-authorization hold

You authorize the card for the deposit amount without capturing. Funds are reserved on the customer's card; no money moves; you capture only if you need to claim, otherwise you void.

• Good: No processing fee on the released amount, no refund delay, cleanest customer experience.
• Bad: Authorization holds expire, commonly within about a week, sometimes less depending on the card scheme and issuer. If your rental period is longer than the hold lifetime, the hold silently dies and you have no deposit.
• Worse: Support is uneven. Not every acquirer, card type, or wallet supports auth-and-capture with the semantics you need. Mobile wallets and cash-based methods generally do not support holds at all.

Option B: charge and refund

You capture the deposit as a real payment and refund it later.

• Good: Works on every payment method, no expiry, amount is guaranteed.
• Bad: You pay the processing fee, and it is usually not returned on refund, so a fully-returned deposit costs you roughly 2.75% of it. Refunds also take days to reach the customer, which generates support tickets.
• Also: That money is a liability sitting on your balance sheet. Do not spend it. Teams do spend it.

Option C: deposit as commitment, not capture

Take card details, store a token, and charge only if damage occurs. Nothing is held or captured up front.

• Good: Zero friction, zero cost, best conversion.
• Bad: Collection rate on a later charge is not 100%. Cards get cancelled, funds are insufficient, customers dispute. This is a commercial risk decision, not a technical one.

You are building a ledger whether you plan to or not

Every marketplace I have seen tries to avoid this and every one ends up building it, usually twice. Build it deliberately the first time.

The minimum viable version is double-entry: money is never created or destroyed, only moved between accounts, and every movement is an immutable entry.

accounts        (id, owner_type, owner_id, kind)
                kind ∈ {customer, provider_payable, platform_revenue,
                        deposit_liability, gateway_clearing}

entries         (id, transaction_id, account_id, amount_minor,
                 direction, created_at)          -- immutable

transactions    (id, kind, external_ref, occurred_at, metadata)
                kind ∈ {capture, refund, deposit_hold, deposit_capture,
                        deposit_release, payout, adjustment, fee}

-- invariant, checked continuously:
SELECT transaction_id, SUM(CASE WHEN direction='debit'
                               THEN amount_minor ELSE -amount_minor END)
FROM entries GROUP BY transaction_id HAVING SUM(...) <> 0;
-- must return zero rows

Non-negotiables, learned the hard way:

• Store money as integer minor units. Piastres, not pounds. Never floating point. This is not a stylistic preference.
• Entries are append-only. Corrections are new reversing entries, never updates. Your ledger is evidence.
• Every entry carries the gateway reference. When you reconcile against a settlement report, that reference is the join key.
• Deposits are a liability account, not revenue. They are visibly separate from money you have earned, in the database and in the dashboard your finance person looks at.
• Run the balance invariant as a scheduled job, and alert on failure. A ledger that silently stops balancing is worse than no ledger.

Add idempotency on every write path keyed by the gateway's transaction reference. Webhooks are delivered more than once, and a double-applied payout is a very bad afternoon.

Evaluating a gateway: the actual checklist

Ignore the marketing page. Ask these, and require answers in writing or in the sandbox.

1. Do you support sub-merchants, and what is the onboarding and KYC process for each one?
2. Can a single charge be split across recipients at capture? What are the limits on the number of recipients?
3. How does a refund behave on a split transaction: is the split reversed automatically, or do I reconcile it?
4. Do you support authorization-and-capture? What is the maximum hold duration, on which card types, and what happens at expiry?
5. Is partial capture supported? (Critical for claiming part of a deposit.)
6. Can I initiate payouts via API, and what is the payout settlement time?
7. What does the settlement report contain, is it available via API, and does it include your fees line by line?
8. Which webhook events exist, are they signed, and what is the retry policy?
9. What is the sandbox coverage: can I test split, refund, hold expiry and payout end to end?
10. Who bears chargeback liability on a split transaction: me or the sub-merchant?

Question 10 is the one that surprises people. On many marketplace products the platform is liable for chargebacks even though the provider received the money, which means you need to be able to claw back from a provider's future payouts, which means your ledger needs negative balances and a recovery policy. Design for it now.

In the Egyptian market specifically, Paymob is the provider with an explicit marketplace product covering sub-merchant onboarding, split payments and downstream payouts, which makes it the default starting point for this shape of business. The others are perfectly good gateways where you will be building the split-and-payout layer yourself. I compare all five in more detail in the Egypt payment gateway comparison.

Failure modes to design for now

• The hold that expired. Rental runs 10 days, authorization dies at 7. Track hold expiry as a first-class date, alert before it lapses, and decide the policy (re-authorize, or accept the exposure) before it happens for the first time.
• The partial refund on a split charge. Customer gets 40% back. Whose 40%? Provider's, yours, or proportional? Write the rule into your terms and encode it once, or every refund becomes a manual decision.
• The provider who owes you money. Chargeback lands after payout. Their balance goes negative. You need a documented recovery path or you write it off.
• The disputed deposit deduction. Provider claims damage, customer denies it. Whatever your policy is, the ledger should record the deduction as an explicit, attributable decision with a reason and an actor, not as an adjusted number.
• The reconciliation gap. Gateway settlement says one figure, your ledger says another. It will happen in week one. Have the daily job and the alert before launch, not after.

What I'd do

Concretely, for a new marketplace with deposits:

1. Settle the licensing question with a lawyer before choosing an architecture. It may make the choice for you.
2. Use a gateway marketplace product for the revenue split if one is available to you, so the regulated money movement stays with the licensed provider.
3. Keep deposits separate: as a hold if your acquirer supports one long enough, otherwise as a captured liability in your own account, priced accordingly.
4. Build the double-entry ledger on day one. It is roughly a week of work at the start and a rewrite of your whole money layer if you defer it.
5. Put the gateway behind an interface. Marketplace requirements are exactly the ones that force a provider change eighteen months in.

The gateway decision gets all the attention, but the ledger is what determines whether you can operate. Gateways are replaceable. A payment history you cannot explain is not.