Acquiring: From a Collection Account to Merchant Transactions
Part II · Extensions to the Architecture (Chapters 6–8) Builds on: Payment Systems, Chapter 6 (interchange and MDR), Chapter 7 (authorization, clearing, settlement and chargebacks), Chapter 8 (card-not-present payments and 3DS), Chapter 9 (push and pull), Chapter 20 (PayFacs and ISOs) New concepts in this chapter: acquiring and acquirer, principal membership and sponsorship, merchant underwriting, chargeback monitoring, local and cross-border acquiring
1. The question from the previous chapter¶
Some of StarMap's European customers are individuals paying €30 a month by card. Why can't the virtual IBAN in pay-in endpoints handle that?
Consider two ways to collect €30.
The first displays StarMap's IBAN at checkout and asks the customer to open a banking app, enter the details and transfer funds. StarMap activates the subscription after receipt. This is a push payment and works with pay-in endpoints, but the extra steps lose customers along the way.
The second lets the customer enter card details and click Pay, activating the service immediately. This is a pull: as push and pull explains, the recipient requests payment using the payer's authorization. Pull payments need authorization before the charge and a way for the payer to challenge it afterward.
A basic pay-in endpoint waits for funds and identifies their owner. It does not ask an issuer to approve a €30 card charge, or manage a cardholder's later claim that the charge was unauthorized. That dispute process can lead to a chargeback. Card acceptance therefore requires additional capabilities.
Acquiring means accepting payments for merchants and taking on the accompanying authorization, settlement, refund and dispute obligations. The provider is the acquirer; StarMap is the merchant.
2. The added lifecycle and responsibilities¶
Follow one €30 subscription charge:
| Stage | What happens | Does a basic transfer pay-in have this step? |
|---|---|---|
| Merchant underwriting | The acquirer reviews StarMap's industry, products and chargeback history, then signs a merchant agreement | No equivalent product-underwriting step; the transfer provider reviews account eligibility |
| Authorization | The acquirer sends the card request to the issuer, which approves €30 within about a second | No card authorization request |
| Clearing and settlement | The acquirer submits the transaction to the scheme; one or two days later issuer funds settle through the scheme, and the acquirer pays StarMap after fees | It also identifies and posts receipts, but without card-scheme clearing or the card fee split |
| Refunds and chargebacks | Three weeks later the user denies subscribing; the issuer raises a chargeback, the acquirer debits €30 plus a dispute fee, and StarMap submits evidence | A settled push-transfer recall is a request that can be refused in the model described earlier |
| Fraud and risk | The acquirer answers to the scheme for StarMap's chargeback exposure and may face penalties | No card scheme, scheme threshold or scheme fine |
The card transaction lifecycle separates authorization, clearing and settlement. Card-not-present payments introduces 3DS, issuer authentication of the cardholder, and the associated fraud-liability shift. Here we are viewing those mechanisms from the acquirer's side.
Suppose the user pays with an EU consumer debit card and interchange is 0.2%, the EU cap used in this example:
| Item | Amount (€) |
|---|---|
| Transaction | 30.00 |
| Issuer interchange, 0.2% | −0.06 |
| Scheme fee | −0.03 |
| Acquirer's own fee | −0.15 |
| StarMap receives | 29.76 |
A chargeback three weeks later debits €30 plus an illustrative dispute fee of about €15. The €45 debit equals one and a half months of subscription revenue, before the staff time spent preparing evidence.
3. Where acquiring fits: a pay-in endpoint with continuing liability¶
Return to the PSP model. Card funds originate with the issuer, settle through the scheme to the acquirer, and are then paid to the merchant. The final step can take two forms:
- Pay the merchant's external bank account, creating a settlement relationship.
- Credit the merchant's PSP balance, if the acquirer also provides a regulated balance core.
In the second form, acquiring acts as a pay-in endpoint connected to the core. It collects funds, identifies the merchant — each transaction already carries a merchant ID — and instructs the core to post them.
It differs from the basic pay-in endpoint in one defining way: responsibility continues after receipt. Card receipts retain chargeback exposure, scheme obligations and merchant-fraud risk. These explain merchant underwriting, chargeback monitoring and rolling reserves, where part of each settlement is held for several months to cover later claims.
The responsibility follows initiation. A payer initiates a push transfer on the payer's side. A merchant initiates a pull using authorization, placing the associated acquiring responsibilities on the recipient's side. The acquirer occupies that side of the relationship.
4. Licensing requirements: who contracts with the card scheme?¶
Acquiring has two permission layers: regulatory payment permissions and card-scheme membership.
Payment permissions: EU law lists acquiring as a payment service, so the institution needs it within its authorized scope. The US has no single federal acquiring licence; scheme-member banks take the central regulated role. This belongs to the same broad licensing framework as the balance core.
Scheme membership: submitting authorization requests to Visa or Mastercard and receiving scheme settlement requires an appropriate scheme relationship. These are the schemes' own rules. Three common roles differ by their relationship to the principal member:
| Role | Who contracts with the scheme? | Who signs merchants? | Who handles funds? | Who ultimately answers to the scheme for chargebacks and fines? |
|---|---|---|---|---|
| Principal-member acquirer | The acquirer itself | The acquirer | The acquirer | The acquirer |
| Sponsored payment facilitator, or PayFac | Its principal-member sponsor | The PayFac; merchants are its submerchants | The PayFac, with settlement through the principal member | The principal member, which can recover from the PayFac |
| Independent sales organization, or ISO | The principal member | It refers merchants to the principal member | It does not handle funds | The principal member |
The industry role map introduced PayFacs and ISOs. This table adds the liability chain. Sponsorship can allow a launch within weeks, but the sponsor controls permitted merchant categories, reserves and continuation of the relationship. Stripe and Square began with sponsored models and later obtained principal membership in some markets as they grew.
Local and cross-border acquiring
Scheme rules also place regional limits on acquiring relationships. Acquiring for a merchant outside the acquirer's region can face restrictions and different economics. For example, an EU acquirer handling European cards for a US merchant has a cross-border acquiring relationship. StarMap's provider choice for US card acceptance therefore requires examining merchant location, regional permissions and card economics. Large acquirers obtain permissions in each major region to offer local acquiring arrangements.
Another route is to let a different company be the seller. A Merchant of Record, or MoR, sells StarMap's software to users and then pays StarMap as its supplier. The MoR contracts with the acquirer, handles chargebacks and manages relevant consumption taxes. In exchange, fees are higher and the MoR's name appears on the customer's statement.
5. Engineering requirements: approvals, chargebacks and settlement reconciliation¶
Three operating measures capture much of the work.
Authorization approval rate: of 100 legitimate payment attempts, how many does the issuer approve? Acquiring location, network tokens that replace raw card numbers, appropriate 3DS exemptions, and the timing or routing of retries can affect the result. Better approval rates let merchants capture more revenue from the customers they already have.
Chargeback rate: chargebacks divided by transactions. Visa and Mastercard have their own monitoring programs and definitions. The course uses roughly 1% as an indicative scale, not a universal threshold. Breaches can trigger monitoring, remediation, fines and eventually termination. Acquirers must monitor each merchant and assess likely exposure during underwriting.
Merchant settlement reconciliation: each transaction in daily scheme clearing files must match the merchant's orders, receipts in the acquirer's settlement account and amounts settled to the merchant. This extends the reconciliation in pay-in endpoints by adding the card scheme. Fee checks are particularly demanding because interchange varies across hundreds of combinations of card, region and transaction type.
| Measure | Who cares most? | Consequence of poor performance |
|---|---|---|
| Authorization approval rate | Merchant | The merchant changes acquirer |
| Chargeback rate | Card scheme | Fines or termination |
| Settlement reconciliation | Merchant and acquirer | Overpayment, underpayment or incorrect fees |
6. Compare acquiring with a transfer pay-in¶
| Basic push pay-in | Card acquiring, a pull | |
|---|---|---|
| Initiator | Payer | Merchant, using payer authorization |
| Payer experience in these examples | Leave checkout to make a transfer | Enter card details at checkout |
| Checkout conversion | Lower | Higher |
| Timing | Seconds on instant rails | Authorization in seconds; funds in one or two days |
| Per-payment cost | Low, largely fixed | Percentage-based, including interchange |
| Dispute responsibility | Generally no card-style dispute mechanism | Acquirer, with recovery from the merchant |
| Permissions | Payment permission plus clearing access | Payment permission plus scheme membership or sponsorship |
| Main engineering measures | Receipt-identification accuracy | Approval and chargeback rates |
Push or pull determines where initiation and the accompanying responsibilities sit. Those responsibilities explain merchant underwriting, disputes and chargeback monitoring. Adding acquiring therefore requires a merchant-risk operation alongside the technical integration.
7. The questions this raises¶
Cards serve many European and North American consumers. But Dutch users expect iDEAL, Brazilian users Pix, Indian users UPI, and many Southeast Asian users QR payments. Most of these are push-based, yet they need checkout integration, immediate confirmation and refunds.
They extend the basic pay-in endpoint in a different way from card acquiring. The next chapter examines how a PSP puts many local payment methods into one checkout.
8. Self-check questions¶
- A PSP already holds an EU PI licence and operates the transfer service described in pay-in endpoints. What else does it need to offer card acquiring? Separate permissions from engineering.
- StarMap's chargeback rate rises from 0.3% to 1.2%. Who reacts, and how do consequences reach StarMap?
- Why can a settled push-transfer recall be a request, while a card chargeback debits funds before the merchant presents evidence? Explain through responsibility for initiation.
9. Answers¶
Try answering before reading on.
Permissions: include acquiring in the licence's scope if necessary, then obtain scheme membership or become a sponsored PayFac. Engineering: merchant underwriting, authorization including 3DS and network tokens, scheme-file reconciliation, chargeback handling and monitoring by merchant. Only part of the existing identification and reconciliation system carries over; card transactions use merchant and transaction IDs rather than virtual accounts.
Under the illustrative threshold scenario, scheme monitoring alerts the acquirer, which contacts StarMap. The scheme can require remediation or fine the acquirer. The acquirer can require StarMap to reduce chargebacks, increase reserves or pay higher fees. Persistent problems may terminate the merchant agreement and leave a record that makes another acquiring relationship difficult. The scheme's consequences reach StarMap through its acquirer.
A push transfer is initiated by the payer through its bank, which checks the payer and available funds. After final receipt, a change of mind generally requires a return request. A card pull relies on authorization used by the merchant, potentially without the cardholder confirming that specific charge at that moment. Scheme rules preserve a later challenge and place the evidence burden on the party presenting the charge. The return mechanism follows that allocation of responsibility.
Previous: Chapter 5 · Putting It Together: A Cross-Border Payment from Start to Finish Next: Chapter 7 · Local Payment Methods: Why Integrate a Hundred Ways to Pay?