NMIBlogger

Independent analysis of payment gateway platforms

GUIDE

Payment gateway integration guide

"Integrating a gateway" can mean anything from pasting in a hosted payment link to building a full server-side API integration with tokenized vaulting. Here's what each path actually involves.

Virtual terminal: no integration required

A virtual terminal is a web-based interface for manually keying in card-not-present transactions — phone, mail, or in-person orders without a physical terminal. It requires no development work, but it doesn't connect to your own software or website; it's a standalone tool layered on top of the gateway.

Hosted payment page / hosted fields

A hosted payment page redirects the customer to a page served by the gateway; hosted fields embed gateway-controlled iframes directly into your own checkout page so it never touches raw card data. Both approaches significantly reduce PCI scope for the merchant or ISV, since card data never passes through your own servers, at some cost to checkout-page customization.

Direct API integration

A direct, server-side API integration gives full control over the checkout experience and transaction flow — recurring billing logic, custom fraud rules, multi-step checkouts — but it means your systems handle card data directly (even if only transiently before tokenizing it), which puts you fully in PCI DSS scope unless you tokenize immediately and never store raw card numbers. This is the path most ISVs building embedded payments choose, using the gateway's SDKs to minimize how much raw data ever touches their own code.

Tokenization and customer vaults

Most modern gateways, including NMI and USAePay, offer a "customer vault" or tokenization layer: once a card is captured, the gateway returns a token that can be used for future charges — recurring billing, saved payment methods — without your systems ever storing the actual card number. This is the single biggest lever for reducing PCI scope after the initial integration.

Testing and certification

Before going live, expect a sandbox/test environment, a set of test card numbers, and in some cases a certification step with the acquirer before real transactions are approved. Build in time for this step — it's a common source of launch-date slippage.

What to ask your gateway's developer support

  • Which SDKs and languages are officially supported versus community-maintained?
  • Is there a sandbox environment with realistic test data, and how long does acquirer certification typically take?
  • What does the tokenization/vault API look like, and how portable are tokens if you switch acquirers later?
General integration background, not vendor-specific documentation. Consult NMI's or USAePay's own developer resources for current SDKs, endpoints, and certification requirements.