The gateway is where a payment is encrypted, tokenized, screened, routed and recorded. It is the part of the system you never notice working — and the part you notice immediately when it is not.
Illustrative diagram of the transaction path. Which environments are enabled on an account is decided during setup.
Six stages, and only the first one involves anybody in your business. Everything after it happens on its own, the same way, whichever front door the payment arrived through.
The payment is entered — tapped at a terminal, typed into a checkout, keyed into the virtual terminal, or posted by an integration.
Card data is encrypted at the point of entry, so the sensitive part is protected before it reaches any system of yours.
The card is replaced with a token that is useless anywhere else. That token, not the card number, is what gets stored for refunds, repeats and recurring billing.
Your risk settings are applied — address and security-code checks, velocity limits, duplicate detection — before anything is sent for authorization.
The transaction is sent onward for authorization on the path configured for your account, and the answer returns to wherever it started.
Approved or declined, it lands in reporting immediately, tagged so it can be found, refunded, reconciled and exported.
The gateway is the routing and record-keeping layer, not the bank. Authorization is the issuing bank’s decision, and settlement runs on your funding schedule. What this layer is responsible for is that every transaction is captured, protected, screened and recorded consistently, whichever way it arrived.
Most businesses need more than one way to take a payment, and each one is a different front door onto the same gateway. Adding another later is a configuration change rather than a second relationship — and all of it keeps reporting in one place.
A hosted checkout collects the card on the gateway’s side rather than yours. Your site hands over the order and receives the result, which keeps card data — and a large part of the compliance burden that comes with it — off your own systems entirely.
A payment link is a single-use or reusable checkout you send by email or text. It suits deposits, quotes, phone bookings and any business that sells without an online store — and it produces exactly the same record as any other transaction.
The virtual terminal turns any computer into a way to take a card over the phone or by mail order. There is no hardware to buy and nothing to install — it is the same gateway, with your staff entering the card instead of the customer.
Card-present terminals connect to the same platform as your online acceptance, so a sale at the counter and a sale on the website land in one report against one merchant account. That is the difference between reconciling once and reconciling twice.
A stored credential is a token, not a card number. Once the customer has authorized it you can charge on a schedule, take a follow-up payment, or settle a balance later, without your systems ever holding anything worth stealing.
Where a shopping cart, booking system or back-office application already exists, the gateway connects to it rather than replacing it. How much work that is depends entirely on the system — which is why it is scoped before anything is promised.
They are quoted together, set up together, and do completely different jobs. You need both, and one without the other does nothing — a gateway with no merchant account has nowhere to send a transaction, and a merchant account with no gateway has no way for an online or keyed payment to reach it.
Connection is a short project with a predictable shape. Knowing the shape is most of what keeps it short.
Most delays here are not technical. They come from discovering late that a cart plugin does not cover a particular flow, that nobody agreed who would test the refund path, or that the descriptor customers will see on their statement was never decided. Working through the order below avoids all three.
What can be enabled, and how it connects, depends on your systems and on the outcome of underwriting.
A separate gateway, bolted to a separate merchant account, bolted to a separate terminal fleet is how a business ends up reconciling three reports and calling three support lines about one payment. One platform underneath all of it means one record of what happened.
If the question is about connecting a specific system, the useful answer comes from someone who can look at it with you.
Talk to SalesThe gateway is the technology that captures, protects, screens and routes a transaction. The merchant account is the banking relationship that lets the money settle to you. You need both, and they are often sold separately by different companies — which is how a business ends up with two contracts, two support lines and two reports covering one payment.
No. A payment link or the virtual terminal will take a card with no website at all, which is how many service and phone-order businesses run. A website simply adds another front door onto the same platform.
Usually — and the honest answer depends on the system. Common shopping carts connect through a plugin; bespoke and industry-specific software connects through a direct integration. What that takes is scoped against your actual platform before anything is committed, which is why you will not find an integration list presented as a promise on this page.
Not with you, when the setup is right. Cards entered through a hosted checkout, or tokenized for repeat billing, are held as tokens — and a token is worthless outside your own account. That is what keeps card numbers off your systems and keeps your compliance scope small.
Every transaction from every channel in one place: searchable, filterable and exportable, with refunds, batches and disputes attached to the transactions they belong to. The point of it is that in-store, online and recurring activity form one report rather than three.
Often, yes. It depends on the make and model and on whether the equipment is locked to your current processor. That gets checked before any change is recommended — replacing hardware that already works is the last option, not the first.
Yes — that is what the virtual terminal is for. Your staff key the card into a browser instead of the customer entering it themselves, which suits phone bookings, deposits and back-office payments. Worth knowing before you rely on it: keyed transactions carry more risk than card-present ones, so they are priced differently and address and security-code checks are normally required.
Timing, and it matters. A payment that has been authorized but has not yet settled can be voided — the transaction simply never completes, and the hold drops off the customer's account. Once it has settled you can no longer void it; you refund it, which sends the money back as a separate movement. Same outcome for the customer, different record, and the cut-off is settlement.
Accept it. Route it. See it.
Restaurant-ready POS, pay-at-table handhelds and equipment with no upfront cost for qualifying merchants. We start with a statement analysis — nothing changes until the numbers make sense.
Promotional terms and eligibility apply. Estimates only. Final pricing requires statement analysis and approval.
