Payment
gateways.

01 / THE FOUNDATION

What is a payment gateway?

A payment gateway is technology that captures or receives payment information and securely passes a payment request into the processing system. It helps connect the customer’s checkout experience to the services that authorize and process the transaction. Depending on the product, it can also provide a hosted payment page, tokenization, fraud controls, reporting, recurring-payment features or integrations.

That description is deliberately narrower than “the company that takes your payments.” Some providers bundle the gateway, processing and merchant services into one offering. Others let a separate gateway connect to a compatible processor and merchant account. The brand on your checkout therefore does not tell you the whole contractual or technical story.

For a business owner, the practical question is this: does the complete setup support the way you sell, the way you get paid and the way you operate? A gateway that works beautifully for a one-time online purchase may need additional software or a different configuration for subscriptions, telephone orders or multiple legal entities.

The cardholder’s issuer is on the other side: it issues the customer’s card and typically decides whether to approve the authorization request. Card networks connect the participating institutions. These roles can be bundled commercially, but their responsibilities still matter when something goes wrong.

Start with our merchant accounts guide if you are choosing the underlying acceptance arrangement. This pillar focuses on the gateway decisions that sit around it.

02 / FOLLOW THE TRANSACTION

An approved payment is only the beginning.

A customer sees a short checkout. Your business depends on a longer chain of events. Understanding that chain makes it easier to diagnose a missing order, an expired authorization or a deposit that does not match the day’s sales.

Authorization: can the transaction proceed?

An authorization request asks the issuer to approve the proposed transaction. An approval can place a hold on available funds or credit; it does not mean that the merchant has received a deposit. Authentication, such as a 3-D Secure flow, can be a separate step in confirming the cardholder’s identity. Authentication and authorization should not be treated as interchangeable events.

Capture: submit the approved transaction for completion.

Some systems authorize and capture together. Others authorize first and capture later, for example when an order is ready to ship. Authorization validity, partial capture, multiple captures and incremental authorization depend on the payment method, network, provider and configuration. Do not assume a hold can remain open indefinitely or that every product supports the same capture behavior.

Clearing and settlement: transaction records and funds move.

After capture, transaction data is submitted through the appropriate processing flow and the institutions settle their obligations. The merchant’s provider then pays out under the account’s funding terms. A gateway’s “captured” status, a processor settlement report and the money available in your bank can represent different moments.

Reconciliation: prove what reached the bank.

Match the order to its payment, refunds, fees, disputes and payout. Keep the provider’s transaction ID, your own order ID and the payout or batch reference connected. Your accounting team should be able to explain a deposit without manually opening hundreds of checkout records.

Provider-specific examples: separate authorization and capture and payout reconciliation. These explain one implementation; confirm your provider’s equivalent behavior.

03 / CHOOSE YOUR CHECKOUT MODEL

Choose the integration your team can actually operate.

More customization creates more responsibility. Start with the customer experience and the systems you need to connect, then choose the lightest integration that meets those needs. A fully custom checkout is not automatically a better business decision.

“API integration” does not necessarily mean your server should handle raw card details. Many custom integrations use a provider-controlled collection component and send tokens or identifiers to the merchant’s server. Review the actual data flow rather than judging security responsibilities from a marketing label.

A payment link is another useful entry point: the merchant sends the customer to a hosted payment page. A virtual terminal serves a different workflow, such as an authorized staff member entering telephone-order details. Confirm pricing, permissions and transaction support separately; availability of a checkout product does not prove that every channel is included.

For an online store, pair this section with our ecommerce merchant account guide. If your business uses several channels, document whether each one shares the same customer records, tokens and reports—or operates as a separate payment setup.

04 / THE COMPATIBILITY TEST

“It integrates” is the start of the conversation.

A logo on an integrations page is useful evidence, but it is not a complete implementation plan. Ask for confirmation of the exact gateway product, processor connection, platform version, country, currency and merchant-account arrangement you intend to use.

Verify the combination, not just the individual pieces.

A gateway may support multiple processors, but a particular plugin may expose only a subset of gateway features. A recurring-billing product might require a specific vault or token setup. A payment method shown in a provider’s global documentation might not be available to your business location or account.

• Commerce: storefront, cart, checkout, subscriptions and order management.
• Operations: inventory, fulfillment, booking, CRM and customer support.
• Finance: invoices, accounting, tax handling, refunds and deposit reconciliation.
• Access: staff roles, approval rules, authentication and audit records.
• Expansion: additional channels, currencies, locations and legal entities.

Ask for a demonstrated workflow.

Give the provider a real scenario: “A customer buys two items, one ships today, the other is canceled, and the original payment is partially refunded.” Ask them to show how the order, capture, refund and accounting records connect. For recurring sales, test a subscription change, a failed renewal and a cancellation.

When a feature is important, record whether it is native, supplied by another app, custom-built or unavailable. Identify the party responsible for each connection and the cost of maintaining it. “Supported with custom development” can be a perfectly reasonable answer, provided it is priced and planned as such.

05 / MATCH THE WAY YOU SELL

Different businesses need different payment behavior.

The right comparison starts with your operating model, not a universal “best gateway” list. Use these examples to identify requirements; they are not claims that any particular provider or NUMUS arrangement includes every feature.

Online retail: checkout through fulfillment.

Prioritize reliable order creation, the required payment methods, refund handling and the right authorization/capture approach. If fulfillment is delayed, confirm the authorization rules and your capture timing. Test mobile checkout, inventory changes and the case where the customer closes the browser after paying.

Subscriptions: permission, identity and lifecycle.

A subscription system needs more than a saved card. It must connect the customer’s agreement to billing dates, changes, cancellation and properly identified subsequent transactions. Confirm how the gateway and billing platform divide responsibility for stored credentials, authentication and merchant-initiated transactions. A token does not replace customer permission.

Review the relationship between subscription billing, gateways and merchant accounts before selecting the stack. Ask what happens when a card expires, authentication is required or the billing platform changes.

B2B and higher-ticket sales: records that travel with the payment.

For invoice collection, ask whether references such as invoice and purchase-order numbers survive through the reports your finance team actually uses. If enhanced commercial-card data matters, verify that the gateway, processor, software and transaction can support the required data—not just that one product advertises “Level 3.” Qualification and savings are not automatic. Our Level 3 processing guide explains the wider decision.

High volume: operating resilience.

Check throughput expectations, provider rate limits, reporting capacity, support escalation and recovery procedures. Multiple processors or routing options introduce extra questions about tokens, settlement and reconciliation. More connections do not automatically create a reliable failover system. See high-volume payment processing for the broader scaling discussion.

Higher-risk models: eligibility before integration.

Subscriptions with long delivery windows, restricted products and other risk-sensitive models can receive different treatment from providers. Be transparent about what you sell, where you sell it and when you fulfill it. A technically compatible gateway cannot override an acquirer’s eligibility decision or an account’s restrictions. Start with the high-risk merchant account overview when that review is relevant.

06 / SECURITY WITHOUT THE SHORTCUTS

Reduce exposure. Understand what remains yours.

A well-chosen payment integration can reduce the systems exposed to sensitive payment data. It does not remove the merchant’s responsibility to operate securely, manage access and validate the applicable compliance requirements with the acquiring or compliance-accepting party.

Hosted checkout does not mean “nothing to do.”

PCI DSS scope and the appropriate Self-Assessment Questionnaire depend on the actual environment and eligibility criteria. Redirecting customers to a third-party payment page and embedding a third-party form in your site are different arrangements. PCI SSC’s guidance for SAQ A specifically addresses script-attack protection for embedded payment forms. Obtain the current requirements for your implementation rather than assuming that every outsourced checkout has identical obligations.

Ask the provider for its current compliance evidence, a description of what it handles and a clear responsibility matrix. Include your ecommerce platform, hosting and third-party scripts in the discussion. A provider’s compliance status is evidence about that provider; it does not automatically validate your complete business environment.

Tokenization: useful, but inspect the details.

Tokens substitute a reference for sensitive payment credentials in particular workflows. A gateway vault token and an EMV payment token are not necessarily the same thing, and a token usable in one environment may not work in another. Ask what kind of token is used, which systems can act on it and what happens during migration. Tokenization does not justify putting sensitive data into support tickets, analytics events or spreadsheets. Card verification codes must not be retained after authorization, including for recurring transactions.

3-D Secure: authentication, not a universal approval button.

3-D Secure supports cardholder authentication for eligible online card transactions. It can involve a frictionless flow or a customer challenge. Strong Customer Authentication requirements, exemptions and implementation details vary by jurisdiction and transaction. Ask how the proposed setup handles the markets you serve and how it recovers when authentication fails or is abandoned. Authentication does not guarantee authorization, prevent every dispute or universally shift liability.

Protect the account behind the checkout.

Use appropriately restricted staff roles, strong authentication, protected credentials and documented access removal when people leave. Separate test and live environments. Define who can issue refunds, change bank details or export reports. Record the minimum information needed for troubleshooting and follow the provider’s guidance on logs and sensitive-data handling.

Start with the PCI SSC document library, EMVCo’s 3-D Secure overview and your acquirer’s current requirements. The workbook is a selection aid, not a compliance certification.

07 / GET THE WHOLE PRICE

The gateway fee is one layer of the bill.

Comparing one provider’s gateway-only fee with another provider’s bundled processing price produces a misleading result. Separate the layers, then compare the same scope, sales channels and volume assumptions.

Understand what triggers each charge.

“Per transaction” can mean different things in different contracts. Ask whether declined authorizations, retries, refunds, voids, verification requests or other operations are billed. Check whether there are monthly minimums, separate batch charges, cross-border fees, additional currency charges or platform fees for using an external provider.

Also ask what happens to fees when you issue a refund, how disputes are charged, what cancellation terms apply and whether any pricing depends on volume commitments. A reserve affects available working capital even though it should not be casually treated as an ordinary processing expense. Funding timing and reserve terms belong in the comparison alongside cost.

Our guide to overlooked payment costs shows why a declined or retried attempt can deserve its own line in the fee comparison.

Before signing, use our merchant processing quote comparison checklist to match fee definitions, contract terms and included services across written offers.

Measure a consistent all-in effective cost.

For a defined period, divide the comparable payment-related fees by the corresponding gross processed sales. Identify exactly which fees you included. Separate one-time implementation costs from recurring costs, and keep the treatment of refunds consistent between offers. A headline percentage cannot explain all of that.

Use our processing fees guide and fee calculator for the wider statement review. The comparison lab below isolates a simplified gateway-and-processing model so you can see how assumptions change the answer.

08 / BUILD FOR THE REAL WORLD

The difficult payment is the one to design for.

A happy-path demonstration is necessary, but it is not enough. Reliable checkout depends on what happens when the browser closes, an API call times out, an issuer declines, a notification arrives late or a customer presses Pay twice.

Separate a decline from an unknown result.

A decline is a response that needs appropriate handling. A network interruption or timeout can leave the result uncertain. Blindly creating a new payment after an uncertain response can cause a duplicate. Follow the provider’s documented idempotency or duplicate-prevention mechanism, retain the appropriate references and check the existing payment’s status before deciding what to do next.

Confirm payment on the server.

A customer returning to a “thank you” page is not sufficient proof of a completed payment. The customer may close the browser, lose connectivity or arrive before an asynchronous method finishes. Use the provider’s supported server-side confirmation and notification workflow. Verify webhook signatures where supported, make handlers safe to run more than once, and account for delayed or out-of-order events.

If your process includes a signed customer permission form, our credit card authorization form guide explains what that record does—and why it is separate from an issuer approving a transaction.

Make failed payments understandable.

Give customers a clear next action without exposing sensitive diagnostic detail. A legitimate cardholder may need to complete authentication, correct information or use another payment method. Repeated attempts should follow provider and network rules, not an indiscriminate retry loop. Keep support records connected to the order so the customer does not have to explain the problem from scratch.

For recurring charges, the failed subscription payment checklist helps you question retry timing, customer communication and the records needed to investigate an unsuccessful renewal.

Measure the whole funnel.

Track checkout starts, payment attempts, successful payments and confirmed orders as distinct events, using appropriate privacy controls. Review abandonment, authorization outcomes and payment errors by meaningful segments such as device, country or payment method. Changes in these measurements are signals to investigate; a gateway replacement does not guarantee a conversion increase.

Implementation examples: idempotent requests and webhook handling. Apply the equivalent guidance for the provider and product you choose.

09 / MAKE FINANCE PART OF THE DESIGN

Reconciliation should survive past the demo.

The payment dashboard is one view of your business. The order system, accounting ledger and bank account each show another. Agree on a common set of references and statuses before going live.

Ask for an example report that includes a completed sale, a partial refund, a dispute, a fee and a payout. Confirm whether amounts are gross or net, which time zone each report uses, and which date represents the sale, capture, settlement or payout. These distinctions can explain apparent mismatches at month-end.

Find out how long reports remain available, whether exports or APIs include stable identifiers and how changes are reflected after the original payment. If multiple locations or legal entities are involved, verify the reporting boundaries and permissions. Never assume that a shared dashboard also means shared settlement or a single merchant agreement.

10 / MAKE A DEFENSIBLE CHOICE

Use a scorecard, not a feature-count contest.

Start with requirements that cannot be traded away: eligibility for the business, processor compatibility, required payment channels, security responsibilities and access to usable financial records. A low price cannot compensate for a failure in one of those areas.

Then weight the qualities that matter most to your operation. A small retailer may prioritize an existing commerce integration and straightforward support. A subscription business may care most about lifecycle handling and migration. A larger operation may place more weight on reconciliation, access controls and documented incident response.

Mark an unanswered question as unknown, not “probably included.” Give the provider a chance to clarify. Keep feature evidence, commercial terms and implementation assumptions together so the decision can be reviewed later.

Our free workbook turns this framework into a requirements inventory, side-by-side provider comparison, cost worksheet and launch plan. It is designed to be useful before the first sales call as well as during final selection.

11 / PLAN THE EXIT BEFORE THE ENTRANCE

Can you switch without losing the payment relationship?

Before choosing a gateway, ask how you would leave it. Portability can involve customer records, vaulted payment credentials, subscriptions, invoices, dispute evidence and historical reports. Those are not all the same dataset, and moving one does not guarantee that the others can move.

Subscription businesses should also plan for cancellations and refund reconciliation: changing the payment connection does not remove the need to explain credits, fees and outstanding obligations.

Get token migration terms in writing.

A token from one vault is not automatically usable in another. Ask whether secure credential migration is supported, who must approve it, which receiving providers qualify, what fees apply and how long the process takes. Use the providers’ documented secure transfer process. Do not ask staff to export raw card data into a spreadsheet as a workaround.

Preserve the financial history.

Refunds and disputes can continue after new sales move elsewhere. Agree on how the old account remains accessible, how refunds are processed, how records are retained and who owns outstanding support cases. Back up permitted reports and document the identifiers needed to trace transactions later.

Run a controlled cutover.

Test the new setup, define a switch window, assign an owner and record a rollback decision. Avoid accidentally billing a renewal in both systems. Monitor the first live transactions, notifications and payouts under the approved production test plan. Retiring the old integration should be a deliberate step after the necessary dependencies are resolved.

Use the processor-switching playbook for the wider migration plan. The gateway belongs inside that plan alongside contracts, customer communication, reporting and funding.

12 / THE LAUNCH CHECKLIST

Make the first live day feel familiar.

Assign one accountable owner for launch, even when several vendors are involved. Give each test an expected outcome and capture evidence in a safe test environment. Provider test credentials and fixtures are preferable to improvising with real customer data.

After launch, compare actual results with the plan. Check payments against orders, refunds against credits and payouts against the bank. Review support incidents and unexpected charges early. A successful first purchase proves only one path; the operating process needs to work repeatedly.

13 / BRING THE PIECES TOGETHER

Start the conversation with your business, not a brand name.

Before speaking with NUMUS, list what you sell, where customers pay, your approximate monthly card volume, average and highest ticket, fulfillment timing and the software you use. Add any recurring billing, invoice collection or international requirements. If you already process payments, a recent statement and a description of what you want to improve can help frame the discussion.

NUMUS can review your processing needs and help you explore available options. Ask us to confirm the proposed gateway and processor combination, relevant integrations, responsibilities and commercial terms before implementation. Availability, approval, pricing, reserves and funding terms depend on the provider’s review and the arrangement offered.

14 / THE QUESTIONS MERCHANTS ASK

Payment gateway FAQs.