Merchant acquiringقبول المدفوعات Acquiring

Merchant acquiring is enabling a shop to take money from its customers, by card or by app. The company doing that job is the acquirer (المستحوذ): it contracts with the shop, passes its transactions to the network, and transfers it the proceeds a day or two later.

A shop owner may think accepting cards begins with buying a terminal. In reality, it begins with a contract and a network of messages.

Why does a shop need approval to accept cards?

This is the strangest part of the product for a beginner. The shop wants to receive money, not borrow it, so why is it assessed and approved or rejected like a loan applicant?

Because the payment provider carries the shop's risk. Picture an online shop selling tickets to a concert three months away. A thousand customers pay today, the shop receives the money in two days, and then the concert is cancelled or the company disappears. All thousand ask their banks for their money back, and the money is no longer at the shop.

So who pays? The payment provider. Which is why onboarding a new merchant is not a signup but underwriting: what does this business do, when are goods delivered, and how many disputes should we expect? A grocery that hands over goods instantly carries almost no risk. A business selling a service delivered months later carries a lot.

That explains three things that otherwise look arbitrary: why some merchants' payouts are delayed, why a portion is held back as a reserve, and why certain business types are refused however respectable the owner. None of it is bureaucracy. It is pricing the risk that the seller vanishes and the dispute remains.

Three roles behind one button

The party that signs the merchant and enables it to accept payments is the acquirer (المستحوذ). The acquirer is not the bank that gave the customer a card. It sits on the merchant side of the transaction. It may be a large bank or a licensed payments company connected to a bank and the card networks. It assigns the merchant an identifier, sets commercial terms, and takes responsibility for settling funds to that merchant.

The payment gateway (بوابة الدفع) is the layer that receives payment details from a checkout page. It does not move the money by itself. It captures the request, protects sensitive data, and routes the message toward the right destination. An online shop sends card and transaction details through a gateway. A shop in a mall sends much the same information from a point-of-sale terminal. Both need a trustworthy message path that does not expose card secrets to every system along the way.

A payment processor (معالج المدفوعات) translates, checks, and carries messages between systems at high speed. The processor is not always a company the merchant can see or contracts with directly. An acquirer may operate its own processor or rent one from a specialist. A large bank can process millions of messages for thousands of merchants. A small startup can reach the same processor through one API. In both cases, the processor handles technical traffic while the merchant's financial relationship remains with the acquirer.

From the tap to usable cash

The journey starts when a customer presses the pay button or taps a card. The gateway sends an authorisation request to the acquirer or its processor. The request then crosses a network such as mada for domestic cards in Saudi Arabia, or an international card network where relevant. It reaches the issuer, which is the bank that gave the customer the card. The issuer checks available funds, limits, fraud signals, and card status. It sends an approval or decline back along the same route.

An approval does not mean riyals have reached the merchant's account. It is the issuer's promise to honour the transaction if its messages and conditions are completed correctly. Clearing (المقاصة) comes later and calculates what each participant owes. Settlement (التسوية) then moves the net funds between participants. The acquirer pays the merchant on its agreed schedule after deducting fees, reserves, refunds, or disputed amounts.

That distinction explains two situations that appear inconsistent. A customer can see a purchase immediately while the merchant waits two days for the money. A merchant can receive one combined payout while its dashboard shows one hundred separate sales. Both happen because authorisation is almost immediate, while settlement is a financial process with timetables, reconciliation, and risk.

Three truths engineers confuse

An engineer needs three truths inside the system. First is the authorisation message, which returns in under two seconds. Second is the transaction record in the provider's books, the system of record for what happened with the network. Third is the merchant's withdrawable balance, which changes only after settlement and reconciliation.

A webhook (خطاف الويب) is the provider's notice to the merchant app when state changes. A "success" notice can arrive before settlement is complete. If a platform ships on the first notice without a clear policy, it sold on a screen promise, not on cash that arrived. Providers also retry webhooks after network failure. The order therefore needs an idempotency key so the same payment is not booked twice.

This maps to the payment lifecycle and ledgers you already met. Authorisation is a message and a hold. Clearing and settlement move net funds later. Daily reconciliation catches gaps between the merchant dashboard and the acquirer statement.

The four numbers a merchant watches

A merchant should not judge a provider by the appearance of its checkout page. The first number is cost. It can include a percentage of transaction value, a fixed fee, and charges for extra services. Refunds, disputes, currency conversion, and terminal rental may add more. A headline such as "2% per transaction" is therefore not enough to compare two offers.

The second number is the approval rate (معدّل الموافقة), the share of legitimate payment attempts that issuers approve. A payment can fail because data is missing, network routing is weak, or a fraud model is too strict. A decline does not always mean the customer lacks money. A capable processor supplies the right data, retries when network rules permit it, and selects the most suitable route.

A small approval improvement can outweigh a large fee discount. Suppose a merchant attempts to collect SAR 1 million. Raising approvals by two percentage points recovers SAR 20,000 of sales. Cutting fees by 0.1% on that million saves only SAR 1,000. The provider with the higher advertised price may produce the lower economic cost.

The third number is chargebacks. A chargeback is not an ordinary refund approved by the merchant. It is a dispute that a cardholder raises through the issuing bank. The cardholder may say the card was stolen, the order never arrived, or the description was misleading. The process requires evidence by fixed deadlines. The merchant may lose the sale value and pay an additional fee. Card networks can place merchants with excessive disputes under monitoring, impose consequences, or eventually remove their ability to accept cards.

The fourth number is payout speed, meaning the time between a sale and usable money arriving. One provider might pay the next day while another takes three days. Faster is not automatically free because the provider bears fraud and refund exposure before some deadlines expire. A delivery driver needs fuel money this week. A large retailer may accept slower settlement for a lower price. In both cases, time is part of the product's cost, not an operational footnote.

The payment provider does not control approval alone. The issuer makes the final decision, the network defines message rules, and the merchant controls which data it collected. This shared infrastructure explains why one payment system can serve a wallet, a shop, and a payroll app. The message and settlement rails can be similar while the interface, contracting customer, and source of funds differ.

A marketplace is not one large shop

The problem becomes harder when one platform collects money for many sellers. A SAR 300 transaction might include SAR 220 for a seller, SAR 30 for a delivery driver, and SAR 50 kept by the platform. The platform cannot safely treat those shares as ordinary database entries and transfer them whenever it likes. It may have received, held, and transmitted money belonging to other people. Those are regulated financial functions.

Splitting one payment among several payees is split settlement (التسوية المقسّمة). That differs from a retailer selling its own inventory. A normal retailer is the seller presented to the customer and receives the price of its own goods. A marketplace connects the customer to independent merchants and may never own the item. Both present one checkout button. The legal ownership of the money underneath that button is different.

Some payment companies therefore offer a product designed for marketplaces. The provider verifies each seller, records its entitlement, and splits settlement under agreed rules. Automation does not turn this into a mere software feature. The regulatory questions remain: who received the money, for whose benefit, and under which licence?

Saudi Arabia: mada, SAMA, and local brands

Saudi Arabia makes the separation between network, regulator, and merchant service easy to see. mada is the national payment network through which many domestic card transactions pass. SAMA, the Saudi Central Bank, supervises the payments sector and licenses payment-service activities under the applicable legal framework.

A company such as Geidea or NearPay appears as the brand the merchant sees on a terminal or checkout page. The customer may see that logo while the message still crosses mada and the activity remains under SAMA supervision. PayTabs is another example of a gateway and acceptance stack for online merchants. The commercial brand is neither the network nor the regulator.

A connection to mada does not authorise every financial activity. A permission may cover payment acceptance or a defined payment service without covering lending or investment management. Reading any Saudi product therefore starts with the function. If the company moves merchant money, begin with SAMA and payment authorisation. If it invests customer money, you move to a different authority.

Acquiring is therefore larger than terminals and checkout buttons. A provider sells a measurable chance of completing the sale, predictable settlement, and a process for disputes. Merchants are not buying technology apart from money. They are buying a financial result they can measure.

That same gap opens the door to a different product. A merchant who sells today and receives the cash two days later has a recurring liquidity problem, sharpest in peak season. So another provider offers the money up front against a share of future sales. At that point the product changes category entirely: what began as a payment service is now credit, and the governing question becomes who absorbs the loss when the merchant does not sell enough to repay.