How Payment Processing Works

How Payment Processing Works

Understanding the basics of how card payments work helps you troubleshoot issues and answer customer questions with confidence. This page explains the payment flow in simple terms — it applies whether you use NMI, Authorize.net, or both.

The Payment Flow

Every time a customer swipespays aby card,card taps— theirwhether in person, over the phone, or types in a card number on your website,website a series of steps happens behind— the scenespayment togoes movethrough moneythree from their account to yours. This page explains how that process works in plain English — no finance degree required.

The Payment Flow: Three Steps to Getting Paid

Think of every credit or debit card transaction as a three-step process:steps:

1. Authorization — "IsThe payment processor asks the moneycustomer's there?"
   When a customer hands you their card to pay for a Glock 19, your system instantly contacts their bank and asks:bank: "DoesIs this card valid, and does the customer have $549enough available?money?" The bank checkssays and sends back either an approvalyes or a decline.no. If approved,yes, thatthe $549funds are put on hold. Think of it like opening a bar tab — the money is heldreserved (reserved) on the customer's card. The moneybut hasn't actually moved yet — it's just set aside so it can't be spent elsewhere.yet.
2. Capture — "Go ahead and take it."
   CaptureThis is the step where you confirmwhen you actually want to collectcharge the money.card. In most CloudFFLcases, setups,this authorizationhappens andautomatically captureright happenafter atauthorization. the same time — the customer pays, and the charge is finalized in one step. However, forFor special orders or layaway situations (say a customer orders a custom Cerakote rifle),layaway, you might authorize the card up frontnow and capture later whenonce the item arrives.
3. Settlement — "Send the money."
   At the end of each businessthe day, all your captured transactions are batched together and sent to the bank infor afinal batch. This is called settlement.processing. The fundsmoney are then transferredmoves from yourthe customers'customer's banksbank intoto your merchant account. SettlementThis typicallyusually takes 1–2 business days, which is why you don't see the money in your bank account the instant someone pays.days.

Card-Present vs Card-Not-Present

Payment processors treat transactions differently depending on whether the physical card is in front of you or not:you:

• Card-Present (CP)present — The customer is standing at your counter and physically inserts, taps, or swipes their physical card on a terminal. Example: a customer walks into your shop and buysbuying a boxGlock of 9mm ammo using the chip reader19 at yourthe register. These transactions are more secure (the chip proves the card is real) and typically have lower processing fees because the risk of fraud is much lower.fees.
• Card-Not-Present (CNP)not-present — The card number is not physicallytyped in frontmanually of— you.either This includes online orders on your website, phone orders whereby you type(phone inorder) or by the cardcustomer number,(online and invoices paid remotely.purchase). Example: a customer calls in to pre-pay for a special-order suppressorsuppressor, andor readsplaces theiran cardorder numberon overyour the phone.website. These transactions havecarry slightly higher processing fees because there's ano greaterphysical riskcard ofto fraud.verify.

Tokenization:Tokenization — Why Card Numbers Aren'tAre Never Stored

You might wonder — whenWhen a customer pays,pays doesby CloudFFLcard savein CloudFFL, their creditactual card number?number is No,never andstored that'sin byyour design.

system.

Here's what actually happens: when a customer enters their card details (either by swiping at a terminal or typing their number online),Instead, the payment system immediatelyprocessor replaces the real card number with a random code called a token. ThatThis token lookscan somethingbe likeused tk_8f3a9b2c1dto —charge meaninglessthe same card again (for future orders or refunds) but is worthless to anyone who seesmight steal it.

This is why you'll sometimes see a returning customer's card listed as something like "Visa ending in 4242" — CloudFFL storesonly knows the last four digits and the token, not the cardfull number. If you need to charge that customer again (for a backorder, a recurring payment, or a refund), the system uses the token to reference the original card without ever exposing the actual number.

If someone broke into your database, they'd find useless tokens — not real card numbers You don't have to worry about storing sensitive card data on your own systems This keeps you inPCI-compliant complianceand withprotects PCI-DSSyour (the security rules that all businesses accepting cards must follow) customers.

Payment Gateway vs Payment Processor

You'll sometimes hear these two terms aused lot,interchangeably, andbut they'rethey easymean toslightly mixdifferent up. Here's the simple version:things:

• Payment Gatewaygateway — The softwaretechnology that securely collects thesends card details andfrom sendsyour themsystem to the right place.processor. Think of it as the "frontsecure door"tunnel —between it'sCloudFFL whatand yourthe websitebank. orNMI terminal talks to. Examples: NMI,and Authorize.net.net are both payment gateways.
• Payment Processorprocessor — The company that actually moves the money between banks. ThinkYour ofgateway ittalks asto the "highway"processor behind the money travels on. Examples: First Data, TSYS, Worldpay. Your processor is usually set up by your merchant services provider.scenes.

InAs everydaya terms:dealer, the gateway takes the order, and the processor delivers the package. You interact with the gateway (through CloudFFL); the processor works in the background.

CloudFFL's

WhatSupported CloudFFLPayment SupportsGateways

CloudFFL integrates withsupports two payment gateways:

gateways.

NMI (Network Merchants Inc.) — A full-featured gateway with support for physical card terminals at your counter, manual card entry, and online payments. This is the most popular choice for FFL dealers with a retail storefront. Authorize.net — A widely-used gateway that handles online card payments and ACH/eCheck transactions. This is a good option for dealers who sell primarily online or want to accept bank transfers.

You can use one or both, depending on your business.needs:

The

NMI — Supports physical card terminals at the POS, manual card entry (key-in), and website payments. Best for dealers with a retail counter. Authorize.net — Supports online card payments and ACH/eCheck (bank transfers). Best for online-only dealers or as a secondary gateway. No physical terminal support.

See the next pagepage, inNMI thisvs chapterAuthorize.net covers— theChoosing differencesYour inProvider, detailfor a detailed comparison to help you decide.decide which one (or both) to set up.