Payments
Take card payments online without putting anyone between you and the money
In markets where most orders are paid at the door, online payment is an addition rather than a replacement — and it has to be built so that adding it cannot break the checkout that was already working. Akkad connects your own gateway account, prices every cart on the server, and refuses to create an order until the payment has been confirmed by the provider itself.
Cash on delivery is not a shortcoming of this market — it is how trust is extended when a shopper has never met the seller. The courier is the escrow. Any commerce platform that treats card payment as the normal path and cash as an afterthought will be wrong about most of the orders it processes, so Akkad starts from the opposite assumption: every storefront and every landing page collects cash on delivery until you decide otherwise, and the pay-online interface is not merely disabled but absent.
Card payment then arrives as a deliberate choice for the merchants who want it. It runs through your own gateway account, funds settle directly to you, and the amount the courier is told to collect drops to zero automatically the moment a payment is verified — so a prepaid order is never charged twice at the door.
01
Cash on delivery is the default, and the fallback
Each storefront and each landing page carries its own payment mode. The mode is resolved when the page is served rather than read from a stored flag, which is what makes the fallback reliable.
| Mode | What the shopper is offered | Why you would choose it |
|---|---|---|
| Cash on delivery | Pay at the door. Every pay-online element is hidden, not greyed out. | The default. Nothing to configure, nothing to maintain, and the behaviour every shopper already expects. |
| Both | Pay now by card, or pay the courier. | The usual first step. Card takes the customers who prefer it without turning anyone else away. |
| Online only | Card payment is the only way to complete the order. | For merchants who will not dispatch on trust — pre-orders, made-to-order goods, high-value items. |
Online mode is only actually served when the plan covers it and a working integration with both credentials exists. If either condition stops being true — a lapsed subscription, a disconnected account — the page quietly serves cash on delivery instead. A checkout that has stopped taking cards still takes orders, which is the only acceptable failure here.
02
The design decision that matters most
No order exists until the payment is verified
The obvious way to build online payment is to create the order, send the shopper off to pay, and mark it paid when the money arrives. That leaves you with a permanent tail of orders that exist but were never paid for — abandoned at the gateway, half-completed, indistinguishable at a glance from real ones. Akkad inverts it. Before the shopper is sent anywhere, the server prices the entire cart itself and writes an intent recording exactly what is expected. Only after the provider confirms that exact amount was actually collected does an order row come into existence.
- 01Price the cart server-sideItems, shipping rules, discounts, promo, tax, rounding — the browser's numbers are never used.
- 02Write a payment intentThe expected amount is recorded before the shopper ever reaches the gateway.
- 03Shopper pays on the hosted pageCard details never touch Akkad or the merchant's storefront.
- 04Verify by calling the provider backA webhook alone is never trusted. Status must be succeeded and the amount must match.
- 05Only now is the order createdAn unverified payment leaves no order behind to reconcile.
The cart is priced entirely on the server
Items, shipping rules, discount rules, the promo code, tax and cash rounding are all recomputed from your live configuration. Nothing the browser sends about money is trusted, so a tampered cart cannot buy anything cheaply.
The intent records the expected amount
That figure is what verification is checked against later. It is written before the shopper ever reaches the gateway, so there is no window in which the expected total could be influenced by anything happening at the payment page.
An abandoned payment leaves nothing behind
A shopper who opens the hosted page and closes the tab produces no order, no stock deduction, and no line in your day. There is nothing to reconcile because nothing was created.
03
What actually happens when a shopper pays
Six steps, and the only one your business sees is the last. The order arrives already paid and already verified.
- 1
The cart is repriced on the server
Every line is resolved against your real catalogue, then shipping rules, discount rules, the promo code, tax and cash rounding are applied in their fixed order. The result is the authoritative total — the same figure order creation would have produced.
- 2
An intent is written
The intent stores the expected amount and everything needed to build the order later. It is a record of a promise, not a sale.
- 3
The provider is given a payment context
Akkad calls your gateway with your own credentials, decrypted in memory for the duration of that call, and receives a hosted payment URL in return.
- 4
The shopper pays on the provider's own page
Card details are entered on the gateway's hosted page. They never touch the storefront and they never touch Akkad.
- 5
Akkad calls the provider back
Rather than believing a webhook, the backend asks the provider directly what happened, using the merchant's credentials, and requires both a succeeded status and an amount matching the intent.
- 6
The order is created, already paid
Stock is deducted, the courier's collect-on-delivery amount is set to zero, the invoice prints with a paid stamp, and you get a push notification tagged with whether it came from a storefront or a landing page.
04
Verification means calling the provider back
A webhook is a message claiming something happened. Treating it as proof is how payment systems get defrauded, so Akkad treats it only as a prompt to go and check.
The provider is the authority, not the notification
Whether the trigger is an incoming webhook or the return page polling, the backend makes its own call to the gateway using your credentials and reads the answer from there. An unsigned or forged message cannot create an order because the message is never the evidence.
Status alone is not enough — the amount must match
Verification requires a succeeded status and a collected amount matching the intent's expected amount within a hundredth. A payment that succeeded for the wrong figure is not a verified payment.
Pending is not a rejection
The three verdicts are verified, rejected and unconfirmed. Only rejected is a final no. An unresolved payment stays unconfirmed and gets checked again, because treating a slow authorisation as a failure would destroy real orders that were about to succeed.
Verification runs under a hard time limit
The whole verification is capped at twelve seconds of wall clock. A gateway having a bad afternoon cannot hold a request open indefinitely; it simply yields unconfirmed, and the check is repeated.
| Verdict | What it means | What Akkad does |
|---|---|---|
| Verified | The provider confirms a succeeded payment for the expected amount. | Builds the order, deducts stock, zeroes the courier's collection, notifies you. |
| Rejected | The provider confirms the payment did not and will not succeed. | Final. No order. The shopper returns to a checkout that still holds their cart. |
| Unconfirmed | The answer is not yet known — still pending, or the provider could not be reached. | Creates nothing and retries. Ambiguity is never resolved by guessing in either direction. |
A database lock is never held across an external call
This one is written down because it was learned in production. Holding a row lock while waiting on a third-party HTTP response means one slow gateway can stall every request queued behind that row. Verification therefore reads what it needs, releases, makes the external call, and only then re-acquires to write. It is an unglamorous discipline that is the difference between a payment provider having a bad day and your whole store having one.
05
Your account, your credentials, your money
Akkad is not a payment facilitator and does not sit in the money path. You connect your own Al Qaseh account; settlement goes from the gateway to you.
Funds settle to you directly
The gateway account is yours, the merchant relationship is yours, and the money moves from the provider to your account without passing through Akkad. There is no payout schedule to wait on because there is no payout — nothing was ever held.
Credentials encrypted at rest
Your client ID and secret are stored encrypted and decrypted only in memory, at the moment a call is made. They are never returned to any client, never written into a page, and never exposed on a public payload.
A probe that verifies without charging anyone
Connecting runs a credential check that asks the provider about a payment ID that cannot exist. The payment lookup is expected to fail; what is being read is whether the authentication succeeded. It proves the keys work without creating a payment, a refund, or a test transaction on your statement.
An Akkad outage never marks you invalid
The probe returns verified, invalid or unknown. If Akkad cannot reach the provider at all, the result is unknown — not invalid. Your working integration is never disabled because of a problem on our side.
Connect, enable, disconnect
The integration is yours to turn off at any time. Disconnecting stops card payment immediately; the storefront reverts to cash on delivery and keeps taking orders.
Sandbox that fails closed
Test integrations point at the provider's test hosts using their published test kit. The allowlist of what counts as a test environment defaults to empty, so the failure mode of a misconfiguration is that nothing runs in test mode — never that real money is treated as test money.
06
When something goes wrong at the worst moment
Payment is where a checkout is most fragile: the shopper has left your site, the network is involved, and a mistake costs real money in both directions. These behaviours exist for the bad path.
The cart is not cleared before the redirect
Emptying the cart on the way to the gateway is the tidy-looking choice and the wrong one. A shopper whose card is declined comes back to a checkout that still holds everything they had chosen, with their details still filled in. They can try again, or switch to cash on delivery, without rebuilding the order.
The return page polls rather than assumes
After payment the shopper lands on a return page that checks status every three seconds for up to forty attempts — around two minutes. That window is sized for a gateway that confirms slowly, so a payment that takes ninety seconds to settle still resolves into a real order in front of the shopper.
A replayed submission cannot charge twice
Each checkout carries a client-generated request ID. A double-tapped button, a retried submission or a lost response resolves to the order that already exists rather than a second payment and a second order.
Blocked customers are refused invisibly
A customer on your block list receives a generic provider-unavailable response. No intent is created and nothing is written. A visible rejection would only teach a spammer to rotate their device or their number, so the refusal is designed to look like ordinary bad luck.
07
A ledger of every payment
Every verification attempt is recorded against the merchant's own payment history, not just the ones that succeeded. Each entry carries the provider's reported status, the approval code, the retrieval reference number, the terminal identifier, the amount that was actually verified, and the raw payload the provider sent. When a customer says they were charged and you cannot find the order, that record is what settles the question in minutes rather than through a support ticket.
The verified flag on an order is deliberately narrow. It is set only by a confirmed gateway payment — never by a staff member marking an order as paid in the app. That distinction is what lets the courier integration safely zero the cash-on-delivery amount: a manually reconciled order still tells the courier to collect, because a note in your system is not evidence that money already moved.
08
Questions
Does Akkad hold my money at any point?
No. You connect your own gateway account and funds settle from the provider directly to you. Akkad stores your credentials encrypted, uses them to create and verify payments, and is never a party to the settlement.
What happens to my checkout if my subscription lapses?
The payment mode is resolved when the page is served, and it falls back to cash on delivery whenever the plan no longer covers online payment. Shoppers keep ordering; only the card option disappears. Nothing is deleted, and restoring the plan restores the card option immediately.
Can a shopper end up paying for an order that was never created?
The flow is built specifically to prevent the inverse — an order that exists without a payment. If a payment is confirmed, the order is built from the intent that was written before the shopper ever reached the gateway, so there is always a record of what the money was for and what it was expected to be.
Why not just trust the webhook? It is signed.
Because a webhook is a claim and a provider lookup is a fact. Calling the provider back with your credentials makes the gateway's own records the authority, and it lets the amount be checked against the intent rather than accepted from the message. The webhook is still useful — it just triggers the check instead of replacing it.
Which currencies and countries are supported?
Storefront online payments are currently built around Iraqi dinar transactions in Iraq. Cash on delivery, by contrast, works anywhere you operate.
What plan do I need?
Storefront online payments are available on the Pro plan and above, and are not included during a trial. Everything else about your checkout — shipping rules, discount rules, promo codes, cash rounding — works on every plan.
Related
Online store
The storefront this checkout belongs to — templates, style presets, custom domains and the checkout form builder.
Orders
What a verified payment turns into: statuses, stock movement, idempotency and the order tracking page.
Growth
Pixels, deferred purchase events and catalog sync — measuring the orders that payment produces.
اسے اپنے ہی کیٹلاگ پر آزما کر دیکھیں
اپنے لیے موزوں پلان سے شروع کریں، اشیاء ایکسل فائل سے درآمد کریں، اور اسی دن چلتا ہوا اسٹور، کاؤنٹر اور آرڈر بک حاصل کریں۔
مفت پلان دستیاب ہے۔ آزمانے کے لیے کارڈ کی ضرورت نہیں۔ درآمد آپ کا موجودہ کیٹلاگ آپ کے ساتھ لے آتی ہے۔