Payment gateways explained for founders

Most founders first encounter a payment gateway when they are wiring up a checkout page, and at that moment it looks like a billing widget. It is not. A gateway is an integration with a global clearing network that has its own rules, timings, and failure modes, and the founders who understand that network are the ones whose payment systems hold up under production load, audits, and disputes.

The players and what each one does

Five parties are involved in every card transaction. The cardholder is the customer holding the card issued by their bank. That bank, the issuing bank, holds the account and approves or declines each authorisation request. On the merchant side, the acquiring bank has agreed to process card transactions on your behalf, and settlement funds flow through it into your account. The card networks, principally Visa and Mastercard, operate the rails connecting acquirers to issuers globally; they set interchange rates, mandate standards such as PCI DSS and 3-D Secure, and adjudicate disputes. The payment service provider, often called a PSP or gateway, is the technology layer between your application and the acquiring bank. It tokenises card data, routes authorisation requests, handles 3-D Secure challenges, and delivers event notifications to your backend. Many PSPs bundle their own acquiring relationship; others sit on top of a separate acquirer.

Understanding who owns each step matters most when something goes wrong. A decline issued by the issuing bank and a network timeout can appear identical until you inspect the response code, and the correct remediation is completely different in each case.

The transaction lifecycle

A card payment is not a single event. It is a sequence of messages across several systems, and treating an authorisation as a completed payment is one of the most common integration errors. Authorisation asks the issuing bank whether the card is valid and whether funds are available; approval reserves the amount but moves no money. A separate capture instruction then tells the acquirer to collect the reserved amount. Separating these two steps is valuable when you need to adjust the amount after confirming stock, or when you want to authorise at checkout and capture only once you dispatch the order. At the end of each business day the acquirer batches captured transactions and submits them to the card networks for clearing, after which the issuing banks debit their cardholders. Payout to your merchant account follows, typically one to several business days later, minus applicable fees. Your order state machine should reflect this full lifecycle, not just the initial approval.

Reducing your PCI DSS burden

PCI DSS, the Payment Card Industry Data Security Standard, applies to any system that stores, processes, or transmits cardholder data. The practical goal for most merchants is to minimise scope so that raw card numbers never reach your servers. There are two common approaches. A redirect, also called a hosted payment page, sends the customer to a page hosted entirely by the PSP at the point of payment. Card data is entered and processed on the PSP's domain, and your application receives only a token or a callback confirming the outcome. This approach minimises PCI DSS scope but gives you limited control over the payment experience. Hosted fields use iframes served by the PSP's domain embedded within your own checkout page. The fields appear to match your design, but card numbers and verification values are captured and tokenised by the PSP before any value is accessible to your JavaScript. This is the most common production approach for businesses that want a seamless checkout without handling raw card data. Either way, the PSP returns a token representing the card, and you store that token rather than the card number; subsequent charges, such as subscriptions or saved-card flows, use the token and the PSP resolves it when submitting to the network.

3-D Secure adds an authentication step on top of authorisation. The cardholder is challenged, or silently authenticated via device fingerprinting, by their issuing bank before the authorisation message is sent. A successfully authenticated 3-D Secure transaction shifts liability for fraud-related chargebacks from you to the issuer. In many markets, and for certain transaction categories under applicable regulations, 3-D Secure is mandatory. Confirm current requirements with your PSP and acquirer, as the rules are updated periodically.

Building for reliability

Payment APIs are external systems. Networks drop, services restart, and your application may dispatch a request that times out before a response arrives.

• Attach a unique idempotency key to each charge request. The gateway treats any subsequent request carrying the same key as a duplicate and returns the original result rather than creating a second charge. The key should be generated per order or payment attempt and must never be reused across different payment intents.
• Handle webhook notifications by acknowledging each delivery promptly with a success response; any heavy processing should happen outside the request cycle. Always verify the notification signature before acting on the payload, and design your handler so that a retried delivery produces the same outcome as the first.
• Automate daily reconciliation against the PSP's settlement reports. Discrepancies surface failed captures that appeared to succeed, duplicate charges, and refunds processed outside your system.

The economics

Interchange is the fee the acquiring bank pays to the issuing bank for each transaction. It is set by the card networks, not by your PSP, and varies by card type, transaction method, and other factors. Interchange is the floor cost embedded in almost every pricing model you will encounter. The merchant service charge is what you actually pay your acquirer or PSP. It covers interchange, the scheme fee charged by the card network, and the acquirer or PSP's own margin. PSPs typically present this as a blended percentage plus a fixed per-transaction amount, or as interchange-plus pricing where the interchange component is passed through separately so you can see it clearly.

Chargebacks occur when a cardholder disputes a transaction and the issuer rules in their favour. The funds are reversed and you are typically charged a separate chargeback fee on top. High chargeback rates attract penalties from the card networks and can lead to account suspension. Implementing 3-D Secure, maintaining clear merchant descriptors on bank statements, and building sound fraud controls all reduce chargeback exposure.

South African payment context

South African merchants operate in a dual-rail environment. Card payments on Visa and Mastercard are the dominant channel for online commerce, but electronic funds transfer, including instant EFT services that initiate and confirm a bank transfer in near-real time, is widely used, particularly for higher-value purchases where customers are reluctant to share card details. All transactions settle in rand. The South African Reserve Bank and the Payments Association of South Africa govern the payments landscape. Your specific compliance obligations are set by your acquirer and should be confirmed directly with them, as regulatory requirements evolve and vary by business type.

Debit orders, including the newer DebiCheck authenticated debit order system, are a separate payment rail suited to recurring collections rather than one-off commerce payments. If your business model involves subscriptions, instalments, or recurring billing drawn from South African bank accounts, it is worth reading about debit orders and DebiCheck before committing to an integration approach. Your data handling obligations under POPIA apply to any personal information collected at checkout, including billing details and contact information; our post on POPIA and security foundations covers the baseline obligations relevant to e-commerce and SaaS businesses.

Build, buy, or integrate a gateway?

Most product teams should integrate an established PSP rather than build payment processing infrastructure from scratch. The compliance requirements, reliability demands, and network relationship overhead are substantial, and the risk of getting them wrong is high. The more meaningful decision is usually one level above: how much of the billing logic, covering subscriptions, invoicing, dunning, and proration, you build yourself versus delegate to a billing platform. Our piece on build versus buy for custom software provides a framework for thinking through that decision.

Lambdaserve is building a Payment Gateway product tailored to the South African market. It is not yet available, but it is on the way. Watch this space for updates as it moves toward launch.

Written by the Lambdaserve team as general, informational guidance for founders and engineers. It is not legal, financial or tax advice. Third-party product names, programmes and logos belong to their respective owners and are referenced for identification only.