How to Accept Payments Online: Gateways, Checkouts, and Costs Explained

What are the pieces, and how do they connect?

Every online payment, no matter the brand names involved, flows through the same three-part machine:

• The merchant account — your relationship with an acquiring bank that authorizes you to accept card payments and settles the money into your business checking. This is the piece that gets underwritten, sets your pricing, and determines how fast you're funded.
• The payment gateway — the software layer that takes card details from your checkout, encrypts them, routes the transaction to the processor for authorization, and returns the approve/decline in about two seconds. A gateway is to online payments what a terminal is to a storefront: the secure device the card "enters" through.
• The checkout — whatever the customer actually sees and types into: a payment page, a form embedded in your site, or the built-in checkout of a store platform.

The flow: customer submits card → checkout hands it to the gateway → gateway sends it through the processor to the card networks and issuing bank → approval comes back → the batch settles → funds land in your account, minus fees, typically next business day (or same-day with the right funding program).

Aggregated services (Stripe, Square, PayPal) bundle all three parts under their master account — quick to start, flat 2.9% + 30¢ pricing, but you're a sub-merchant on someone else's account, subject to their risk algorithms and their pricing forever. A dedicated setup unbundles the stack: your own merchant account, your choice of gateway, your choice of checkout. For a Dallas business doing real online volume — roughly $10k/month and up — the unbundled route usually wins on cost, funding control, and support, and it's the architecture this guide assumes.

Hosted checkout, embedded fields, or full store?

Your checkout decision drives three things simultaneously: conversion, development effort, and PCI scope. The three architectures:

The honest guidance: most service businesses over-build. If you send invoices or take deposits, a hosted page does everything you need on day one. If you're a retailer, a platform like Shift4Shop gets you catalog, cart, abandoned-cart emails, and a compliant checkout without stitching parts together — and because it's built around Shift4 processing, the store, gateway, and merchant account arrive pre-wired instead of as three support tickets pointing at each other. Custom embedded checkouts make sense when checkout experience is genuinely a competitive edge — and when you have a developer who understands that how the fields are embedded decides your PCI questionnaire (more on that below).

Which gateway should you use — and what does it cost?

Two gateways cover the large majority of dedicated-merchant-account eCommerce, and both are ones we deploy:

NMI is the modern workhorse: hosted payment pages, iframe fields (Collect.js), a customer vault for tokenized card-on-file, recurring billing, level-2/3 data support for B2B cards, and native fraud tooling. Its biggest structural advantage is being processor-agnostic — NMI sits in front of many acquirers, so if you ever change processors, your gateway, your integrations, and critically your stored customer tokens can come with you. That portability is leverage you'll be glad you kept.

Authorize.net is the elder statesman — running since the late 1990s, integrated with practically every shopping cart, invoicing tool, and CRM ever written. Its Customer Information Manager handles stored cards and subscriptions, and its Advanced Fraud Detection Suite provides rule-based screening. If a niche software package integrates with exactly one gateway, that gateway is usually Authorize.net.

What gateways cost, in industry-typical terms:

• Monthly gateway fee: $10–$25
• Per-transaction fee: 5–10¢ on top of processing
• Add-ons: advanced fraud suites, account-updater services, and level-3 modules can add $5–$20/month each where you need them

Two cautions. First, gateway fees are a favorite place for markup padding — a $25/month gateway resold at $60 is a junk fee wearing a uniform, the same species we catalog in our processing-cost guide. Second, beware gateway lock-in: some processors put you on a proprietary gateway and then hold your stored-card tokens hostage when you try to leave. Ask before boarding: "If I leave, do my customer tokens migrate?" The right answer is yes, via standard token export.

Why does card-not-present cost more?

Because the card networks price risk, and a typed-in card is riskier than a tapped one. When a chip or NFC tap authenticates a physical card, counterfeit fraud is nearly impossible and the issuing bank charges less interchange. When digits are typed into a form, the network can't know who's holding the card — so card-not-present interchange runs roughly 0.3–0.5 percentage points above the equivalent card-present rate, before anything else is added.

Stack the full picture and the online premium is structural, not a rip-off:

• Higher interchange on every transaction, per above.
• Downgrade risk: keyed transactions that skip AVS or settle late fall into still-costlier interchange buckets.
• Gateway costs: the monthly and per-item fees from the last section.
• Fraud and disputes: chargebacks skew heavily card-not-present, and each costs a $15–$25+ fee plus the lost goods.

Net result: a well-run online business typically lands at an all-in effective rate of 2.9%–3.6%, versus 2.5%–3.0% for an equivalent storefront. If your online effective rate is over 4%, something specific is wrong — padded markup, downgrades from missing AVS data, or a fraud problem — and each of those is findable and fixable. And if you sell high tickets to businesses, level-2/3 data can claw back real money: passing tax and invoice detail on corporate cards qualifies transactions for lower B2B interchange, often saving 0.5–1.0 point on those sales.

Which fraud tools actually matter?

Online, you are the fraud department. Four tools do most of the work; all are cheap or free, and the first two should be non-negotiable settings on day one:

• AVS (Address Verification Service) checks the billing street number and ZIP against the issuing bank's records. Set the gateway to decline full mismatches. Bonus: AVS participation is also required for the best card-not-present interchange rates — this setting literally lowers your cost per transaction.
• CVV verification requires the three- or four-digit code, which merchants are prohibited from storing — so a criminal with a stolen card number (from a breach dump) usually doesn't have it. Require it, and auto-decline mismatches.
• Velocity rules catch card-testing: bots firing dozens of small authorizations to find live cards. Rules like "max 3 attempts per card per hour," "max 5 transactions per IP per day," and a minimum transaction amount shut down the pattern that otherwise burns you twice — once in per-auth fees, again in disputes.
• 3-D Secure (3DS2) — Visa Secure / Mastercard Identity Check — authenticates the cardholder with their bank during checkout, usually invisibly. Its superpower is the liability shift: fraud disputes on 3DS-authenticated transactions generally move to the issuing bank. Use it on high tickets, first-time customers, and any vertical with a fraud problem; use it selectively if checkout friction worries you.

Layer in the free basics — matching descriptor, instant email receipts, visible refund policy, delivery confirmation on shipped goods — and you've eliminated the majority of both true fraud and "friendly fraud." For the dispute-handling side of the story, see our small business chargeback guide.

How do card-on-file and recurring billing work?

The mechanism that makes stored cards safe is tokenization: the gateway vaults the real card number and hands your systems back a token — a reference ID that can charge that customer through your gateway and is worthless anywhere else. The customer enters their card once; every future charge references the token. Your systems never hold card data, which keeps your PCI scope small and your breach exposure near zero. (For the deeper mechanics, see our tokenization and P2PE explainer.)

What tokens unlock:

• Subscriptions and memberships: the gateway's recurring engine bills weekly/monthly/annually, retries failed payments on a schedule, and emails receipts.
• Card-on-file convenience: repeat customers check out in one click; service businesses charge the card on file when the job completes, with the customer's stored authorization.
• Account updater: when a vaulted card expires or is reissued, network account-updater services refresh the token automatically — the single biggest fix for involuntary churn in subscription businesses.

Two compliance notes worth taking seriously. Card-brand rules require clear disclosure of recurring terms at signup, and receipts for each recurring charge, and an easy cancellation path — the FTC's negative-option rules point the same direction. And keep a signed or click-through stored-credential authorization on file for every card-on-file customer; it's the document that wins the "I never agreed to this" dispute.

What does PCI compliance look like online?

PCI DSS applies to everyone who accepts cards, but how much of it applies to you online comes down to one architectural question: can your systems touch card data? Your answer determines which Self-Assessment Questionnaire you complete:

• SAQ A — the short form, roughly two dozen requirements — applies when card entry is fully outsourced: hosted payment pages, or embedded fields implemented as gateway-served iframes. Your site never sees a digit. This is the scope you want, and hosted/iframe checkouts exist largely to keep you here.
• SAQ A-EP — 150+ requirements, including vulnerability scanning and substantially more security process — applies when your website's own code affects the card entry process: direct-post forms, or JavaScript integrations where your scripts handle the fields. Same website appearance, several times the compliance workload.

This is why the checkout-architecture decision from earlier matters more than it looks: choosing an iframe implementation over a direct-post one can be the difference between an afternoon of questionnaire and a genuine ongoing security program. Whichever form applies, actually complete it annually — otherwise processors bill PCI non-compliance fees of $30–$100/month for a task that, at SAQ A scope, takes about an hour. Newer PCI DSS 4.x requirements also put attention on eCommerce script integrity and monitoring for skimming attacks even at SAQ A scope, so keep your platform and plugins patched. The full walkthrough is in our PCI compliance guide for small businesses.

What if you just need to invoice and get paid?

A large share of "we need online payments" conversations aren't about carts at all. Contractors, consultants, medical and professional offices, wholesalers — they need to send a bill and get paid without waiting 45 days. The toolkit:

• Emailed invoices with a pay button: the gateway or an invoicing layer (Biller Genie and similar tools, or QuickBooks synced to your gateway) emails the invoice; the customer clicks and pays on a hosted page. Automated reminders chase the slow payers so you don't have to.
• Pay links and QR codes: a link that opens a payment page for a set amount — textable, emailable, printable on a paper invoice. No website required at all.
• Virtual terminal: a browser page where your office keys in a card taken over the phone. Fine as a backup; as a primary channel it earns the worst interchange and the most disputes, so push customers to the self-pay link where they type their own card — better rates, better AVS data, better paper trail.
• ACH for the big tickets: on a $8,000 invoice, a card at 3% costs $240 while ACH typically costs a dollar or so. Offering both — card for speed and convenience, ACH for large amounts — is the right default for invoice-driven businesses; we run the full comparison in ACH vs. credit cards for invoicing.

The pattern we see across DFW service businesses that switch from paper-and-check to emailed invoices with pay links is consistent and dramatic: payment cycles compress from weeks to days, because the moment of willingness-to-pay and the ability-to-pay finally coincide. The technology is the cheap part; the cash-flow change is the point.

Frequently asked questions