Card payments
Card payments: from the terminal to the acquirer and back to the ledger
EMV terminals and payment gateways connected to acquirers over ISO 8583 or APIs, with settlement files reconciled in the ERP.
Blueprint
Scroll sideways to see the whole drawing.
Card payments: authorised at the till, settled later, reconciled in the ERP
The terminal or checkout asks the gateway, the gateway asks the acquirer, and the acquirer routes to the card scheme and issuer. Settlement files arrive later and are matched to sales and fees in the ERP. A timeout triggers a reversal so the customer is never charged twice.
- Primary flow
- Asynchronous
- Exception path
The flow, step by step
- From EMV terminal or online checkout to Payment gateway: Authorisation request, over EMV · REST/JSON (primary flow).
- From Payment gateway to Acquirer: Authorisation, over ISO 8583 (primary flow).
- From Acquirer to Card scheme and issuer: Routed to the issuer, over ISO 8583 (primary flow).
- From Acquirer to Payment gateway: Approved or declined, over ISO 8583 (asynchronous).
- From Acquirer to Integration layer: Settlement and fee files, over SFTP (asynchronous).
- From Integration layer to ERP: Settled sales, fees and payouts, over REST/JSON (primary flow).
- From Payment gateway to EMV terminal or online checkout: No response in time: automatic reversal, over ISO 8583 0400 (exception path).
- From Integration layer to Payments operations team: Settlement mismatch or chargeback (exception path).
Overview
This is the path of a card payment, from the terminal or online checkout to the acquirer, the card scheme and the issuer, and back. The customer waits for the answer at the till. The money, minus fees, arrives later in a settlement file that has to be matched to the sales in your ERP.
The reference design sends authorisations through a payment gateway that tokenises the card and routes the request to the acquirer, over ISO 8583 or the acquirer’s API. Settlement and fee files are collected by the integration layer, matched to the original sales and posted to the ERP as sales, fees and payouts.
The design also covers what goes wrong. A request that gets no answer in time is reversed, so the customer is not charged twice. A settlement that does not match, or a chargeback, goes to your payments operations team with the original sale attached.
How the flow works
- 01
Start at the terminal or checkout
The EMV terminal reads the chip or contactless card, or the online checkout collects the card through a hosted page, and sends an authorisation request to the gateway.
- 02
Authorise through the gateway
The gateway replaces the card number with a token and sends the authorisation to the acquirer, over ISO 8583 or the acquirer’s API.
- 03
Route to the issuer
The acquirer routes the request through the card scheme to the issuer, which approves or declines it.
- 04
Return the answer
The approval or decline returns along the same path to the terminal or checkout, with its response code.
- 05
Receive settlement
The acquirer later sends settlement and fee files, which the integration layer collects and validates.
- 06
Match and post
The layer matches settled transactions to the original sales and posts sales, fees and payouts to the ERP.
When something fails
No answer in time
If the gateway gets no response within the acquirer’s time limit, it sends a reversal, an ISO 8583 0400 message or its API equivalent, so the customer is never charged for a sale that did not complete.
A payment is declined
The response code reaches the till or checkout with a clear message. Decline rates are monitored, so a jump that points to a technical fault raises an alert.
Settlement does not match
A settled amount that differs from the sale, or a sale with no settlement, goes to a review list for your payments operations team, with both records side by side.
A cardholder disputes a payment
The acquirer’s dispute report is imported and linked to the original sale and settlement, so your team can respond with the evidence in one place.
Standards and systems
- Banking standards and channels
- SFTP (H2H)
- Payments
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
- Integration
- REST
- Webhooks
Questions and answers
What is the difference between a gateway and an acquirer?
The acquirer is the bank or licensed institution that processes card payments for you and pays out the money. The gateway is the technical service in front of it that accepts requests from terminals and checkouts, tokenises cards and routes them. Some providers are both. The design works either way and keeps the two roles clear.
Link to this questionDoes this keep card data out of our systems?
That is the aim of the design. Card numbers are captured by the certified terminal or a hosted payment page and replaced by tokens at the gateway, so your POS, ERP and data stores only ever see tokens. This reduces the part of your estate that PCI DSS applies to. Your assessor confirms the final scope.
Link to this questionIs ISO 8583 the same for every acquirer?
No. ISO 8583 defines a structure, and each acquirer or network publishes its own specification of fields, message types and codes. That is why we build from the acquirer’s specification and run its certification tests. A gateway API in front of the acquirer hides these differences, which is often simpler for retailers.
Link to this questionWhy does settlement arrive later than the sale?
Authorisation only reserves the funds. The acquirer settles in batches, after deducting its fees and any scheme charges, and pays out on its own schedule. That is why the design treats authorisation and settlement as separate events and matches them, so finance can see what was sold, what was settled and what is still to arrive.
Link to this questionDo you support EMV 3-D Secure for online payments?
Yes. For online card payments we integrate EMV 3-D Secure through the gateway, so the issuer can authenticate the cardholder where regulation or risk requires it. We handle the challenge and frictionless flows in the checkout and test both with the provider’s test cards.
Link to this questionCan we use more than one payment provider?
Yes. The integration layer keeps one internal model of a payment and maps it to each provider, so you can route by channel, country or card type, or move volume between providers. Each provider still needs its own integration and certification, which we plan provider by provider.
Link to this questionTell us what you need to build or connect.
Describe the systems, the timeline and the constraints. The right engineers take it from there.
- Our team will call you within 24 hours during your preferred time slot
- Our team is available 24/7