Payment gateway integration in one minute
What is payment gateway integration, and how does it work?
Payment gateway integration is connecting your website, app or software to a payment gateway so customers can pay by card or bank account. The gateway securely carries each payment from your checkout to the processor and card networks, then returns an approval or decline in a few seconds.
What you need to integrate a payment gateway
Gather these first so development doesn’t stall waiting on approvals. Not sure how the pieces fit? Read merchant account vs payment gateway.
- An approved merchant account — the account that receives your card funds. Merchant accounts are approved through underwriting.
- A gateway account — such as NMI or Authorize.net, linked to that merchant account.
- Sandbox credentials — a free test account so you can build without moving real money.
- API credentials — a public key for the browser and a private key for your server only.
- An HTTPS website — payment scripts and forms must load over a secure connection.
- A plan for PCI DSS — know which self-assessment questionnaire your method will put you in.
5 ways to integrate a payment gateway, compared
Every gateway offers several ways to connect. The right one depends on where customers pay, how much design control you want and how much security work you can take on.
| Method | How it works | Checkout control | Dev effort | Typical PCI SAQ |
|---|---|---|---|---|
| Hosted payment page | Customer is sent to (or shown in a pop-up) a payment page hosted by the gateway. | Low to medium (logo, colors, fields) | Low | SAQ A |
| Hosted fields / JS tokenization | Gateway script turns card details into a token on your own page; your server charges the token. | High | Medium | SAQ A or A-EP, depending on how the form is built |
| Direct API (server-to-server) | Card data is collected and sent by your own server. | Full | High | SAQ D (largest scope) |
| E-commerce platform plugin | An extension connects your store platform to the gateway. | Depends on the plugin | Low | Depends on whether the plugin uses hosted fields or a hosted page |
| Virtual terminal and invoices | Staff key in payments in the gateway portal, or send invoices and payment links. | None needed | None | SAQ C-VT for keyed virtual terminal payments |
How your integration method changes your PCI scope
PCI DSS applies to every business that accepts cards. Under PCI SSC guidance, SAQ A needs every element of the payment page to come from a PCI DSS compliant service provider. SAQ A-EP covers e-commerce sites that don’t receive card data but control how it reaches the processor. Your acquiring bank confirms which questionnaire you file.
- SAQ A — hosted payment pages and gateway-hosted forms. Authorize.net says Accept Hosted lets you keep “SAQ-A level PCI compliance”.
- SAQ A-EP — your own payment form that sends card data straight from the browser to the gateway. Authorize.net describes Accept.js with your own form as a “PCI-DSS SAQ A-EP solution”.
- SAQ D — card data passes through your servers. Avoid this unless you truly need it.
- Keep scripts in check — whatever the method, limit and monitor the scripts that run on pages with your payment form.
Which integration method fits your project?
Answer four quick questions to see the method we’d recommend, the typical PCI questionnaire, and the matching NMI and Authorize.net tools.
Hosted payment page
A starting point, not a compliance ruling. Your acquiring bank confirms which PCI SAQ applies.
Official integration tools for NMI and Authorize.net
Payment Circle sets merchants up on both gateways. Here is what each one offers developers, based on their own documentation. For a feature comparison, see NMI vs Authorize.net.
NMI integration
NMI recommends its newer tools for new builds and keeps its classic APIs for existing integrations.
- Payment Component — a drop-in payment UI that tokenizes card, ACH and digital-wallet details in the browser. NMI recommends it for new integrations.
- NMI REST API — your server charges the token using your private API key, which must never appear in client-side code.
- Hosted Payment Page — NMI says no payment data touches your servers.
- Collect.js and the classic Payment API — for existing integrations. Collect.js tokens are single-use and expire after 24 hours.
- Customer Vault and recurring billing — store payment details as tokens and run subscriptions.
- Sandbox — build against NMI’s sandbox environment before switching to production keys.
Authorize.net integration
Authorize.net’s Accept suite covers hosted and self-hosted checkouts, plus a full API.
- Accept Hosted — a mobile-optimized hosted form shown by redirect, lightbox or embedded iframe. Its form token is valid for 15 minutes.
- Accept.js — tokenizes card data on your page into a payment nonce (
opaqueData) that is valid for 15 minutes. Needs your API Login ID and Public Client Key, and an HTTPS page. - API —
createTransactionRequestwith types such asauthCaptureTransactionandauthOnlyTransaction. - Customer Profiles and Recurring Billing (ARB) — stored payment profiles and subscriptions.
- Webhooks — event notifications signed with HMAC-SHA512 in the
X-ANET-Signatureheader. - Sandbox —
apitest.authorize.netfor testing andapi.authorize.netfor production.
How to integrate a payment gateway in your website
The integration process, from sandbox to live
These steps apply to most gateways and most stacks. Plan one to three weeks for a custom checkout, including testing and approvals.
- 1. Choose your method — use the tool above and confirm the PCI SAQ with your acquirer.
- 2. Open a sandbox — create test credentials and keep them separate from live keys.
- 3. Build the payment form — load the gateway’s hosted page, hosted fields or tokenization script over HTTPS.
- 4. Charge from your server — send the token, amount and your order ID to the gateway API with your private key.
- 5. Handle every response — approvals, declines, errors and timeouts, with clear messages for the customer.
- 6. Add webhooks — verify each notification’s signature, then update orders, refunds and subscriptions.
- 7. Turn on fraud tools — AVS, CVV, velocity rules and 3-D Secure where available.
- 8. Test, then go live — run the checklist below, switch to production keys and endpoints, and watch the first transactions.
Example: charge an Accept.js payment nonce (Authorize.net)
After Accept.js returns the nonce in the browser, your server sends it to https://apitest.authorize.net/xml/v1/request.api (sandbox) or https://api.authorize.net/xml/v1/request.api (live). The nonce stands in for the card details.
{
"createTransactionRequest": {
"merchantAuthentication": {
"name": "YOUR_API_LOGIN_ID",
"transactionKey": "YOUR_TRANSACTION_KEY"
},
"refId": "order-1042",
"transactionRequest": {
"transactionType": "authCaptureTransaction",
"amount": "49.00",
"payment": {
"opaqueData": {
"dataDescriptor": "COMMON.ACCEPT.INAPP.PAYMENT",
"dataValue": "PAYMENT_NONCE_FROM_ACCEPT_JS"
}
}
}
}
}Example: verify a webhook signature
Authorize.net signs each webhook with an HMAC-SHA512 hash of the body using your Signature Key, sent in the X-ANET-Signature header. Reject any notification whose hash doesn’t match, and reply with HTTP 200 quickly. Authorize.net retries failed deliveries and can mark a webhook inactive.
// Node.js (Express): verify an Authorize.net webhook before trusting it
const crypto = require("crypto");
app.post("/webhooks/authorize-net", express.raw({ type: "application/json" }), (req, res) => {
const sent = String(req.get("X-ANET-Signature") || "").replace(/^sha512=/i, "").toUpperCase();
const expected = crypto
.createHmac("sha512", process.env.ANET_SIGNATURE_KEY)
.update(req.body) // raw body, exactly as received
.digest("hex")
.toUpperCase();
const ok = sent.length === expected.length &&
crypto.timingSafeEqual(Buffer.from(sent), Buffer.from(expected));
if (!ok) return res.sendStatus(401);
res.sendStatus(200); // answer fast, then process
const event = JSON.parse(req.body.toString("utf8"));
queueJob(event.eventType, event.payload); // e.g. net.authorize.payment.authcapture.created
});How to test your payment gateway integration
Test every path, not just a successful sale. Sandbox transactions never reach a bank, so you can try declines, mismatches and refunds safely.
| Authorize.net sandbox test | What to enter | Expected result |
|---|---|---|
| Visa approval | 4111111111111111, any future date | Approved |
| Mastercard approval | 5424000000000015, any future date | Approved |
| American Express | 370000000000002, 4-digit card code | Approved |
| Discover | 6011000000000012 | Approved |
| General decline | ZIP code 46282 | Declined (response code 2) |
| AVS mismatch | ZIP code 46205 | AVS result N (no match) |
| CVV mismatch | Card code 901 | CVV result N (no match) |
Testing tips that save launch-day surprises
These values come from Authorize.net’s testing guide. NMI publishes its own test data in its developer docs, so use NMI’s values when you test against the NMI sandbox.
- Keep the sandbox in live mode — Authorize.net notes that test-mode transactions aren’t stored and return a transaction ID of zero.
- Don’t mix credentials — sandbox and production keys aren’t interchangeable.
- Load the right script — use the sandbox version of Accept.js (
jstest.authorize.net) while testing. - Test webhooks end to end — including a bad signature, which your endpoint should reject.
- Test refunds and voids — on both settled and unsettled transactions.
Payment gateway go-live checklist
Tick what your integration already covers, then print it or save it as a PDF for your team or client handover.
Accounts and credentials 0 of 4
Checkout and PCI scope 0 of 5
Transactions 0 of 5
Fraud and security 0 of 4
Webhooks and recurring billing 0 of 3
Go-live 0 of 4
Payment gateway integration: common questions
How long does payment gateway integration take?
A plugin or hosted payment page can be live in a day or two once your merchant account is approved. A custom checkout with tokenization, webhooks and recurring billing usually takes one to three weeks, including testing.
Do I need a merchant account to integrate a payment gateway?
Yes. The gateway carries the transaction, but a merchant account is what lets you accept card payments and receive the funds. Many businesses get both together.
Which integration method is most secure?
Methods that keep card data off your servers, such as hosted payment pages and hosted fields or tokenization, carry the least risk and the smallest PCI scope.
Can I use NMI or Authorize.net with WooCommerce or another platform?
Usually, yes. Most popular e-commerce platforms have extensions for major gateways. Choose one that uses a hosted page or tokenization, and check that it’s actively maintained.
What is tokenization in payment processing?
Tokenization replaces card details with a random token that is useless if stolen. Your server stores or sends the token, and the gateway maps it back to the real card.
How do I test a payment gateway integration?
Use the gateway’s sandbox with its published test card numbers and triggers for declines and mismatches. Test sales, refunds, voids, webhooks and failed payments before switching to live credentials.
Sources and further reading
- Authorize.net: Accept.js
- Authorize.net: Accept Hosted
- Authorize.net: API reference
- Authorize.net: Webhooks
- Authorize.net: Testing guide
- NMI: Developer quick start
- NMI: Collect.js
- PCI Security Standards Council: SAQ A-EP
- PCI Security Standards Council: FAQ on SAQ A and SAQ A-EP eligibility
Related guides
Building payments for your clients? We set up merchant accounts with NMI or Authorize.net gateways for agencies, developers and software companies, and help with sandbox and go-live. Call (571) 274-7950.
Talk to our team →