How Payment Processing Works

~~Test~~Every time a customer swipes a card, taps their phone, or types in a card number on your website, a series of steps happens behind the scenes to move money 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:

Authorization — "Is the money there?"
When a customer hands you their card to pay for a Glock 19, your system instantly contacts their bank and asks: "Does this card have $549 available?" The bank checks and sends back either an approval or a decline. If approved, that $549 is held (reserved) on the customer's card. The money hasn't moved yet — it's just set aside so it can't be spent elsewhere. Capture — "Go ahead and take it."
Capture is the step where you confirm you actually want to collect the money. In most CloudFFL setups, authorization and capture happen at the same time — the customer pays, and the charge is finalized in one step. However, for special orders or layaway situations (say a customer orders a custom Cerakote rifle), you might authorize the card up front and capture later when the item arrives. Settlement — "Send the money."
At the end of each business day, all your captured transactions are sent to the bank in a batch. This is called settlement. The funds are then transferred from your customers' banks into your merchant account. Settlement typically takes 1–2 business days, which is why you don't see the money in your bank account the instant someone pays.

Think of it like a bar tab. Authorization opens the tab (reserving the funds). Capture is when you close out the tab (confirming the final amount). Settlement is when the bar actually gets paid by the credit card company.

Card-Present vs Card-Not-Present

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

Card-Present (CP) — The customer is standing at your counter and physically inserts, taps, or swipes their card on a terminal. Example: a customer walks into your shop and buys a box of 9mm ammo using the chip reader at your register. These transactions have lower processing fees because the risk of fraud is much lower. Card-Not-Present (CNP) — The card is not physically in front of you. This includes online orders on your website, phone orders where you type in the card number, and invoices paid remotely. Example: a customer calls to pay for a special-order suppressor and reads their card number over the phone. These transactions have slightly higher processing fees because there's a greater risk of fraud.

Always use the chip reader when the customer is in the store. Typing in a card number manually when the customer is standing right there (called "key-in") costs you more in processing fees and increases your fraud liability. Only key-in a card when you have no other option.

Tokenization: Why Card Numbers Aren't Stored

You might wonder — when a customer pays, does CloudFFL save their credit card number? No, and that's by design.

Here's what actually happens: when a customer enters their card details (either by swiping at a terminal or typing their number online), the payment system immediately replaces the real card number with a random code called a token. That token looks something like tk_8f3a9b2c1d — meaningless to anyone who sees it.

CloudFFL stores the token, not the card 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 in compliance with PCI-DSS (the security rules that all businesses accepting cards must follow)

Payment Gateway vs Payment Processor

You'll hear these two terms a lot, and they're easy to mix up. Here's the simple version:

Payment Gateway — The software that securely collects the card details and sends them to the right place. Think of it as the "front door" — it's what your website or terminal talks to. Examples: NMI, Authorize.net. Payment Processor — The company that actually moves the money between banks. Think of it as the "highway" the money travels on. Examples: First Data, TSYS, Worldpay. Your processor is usually set up by your merchant services provider.

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

You don't need to pick a processor separately. When you sign up with a gateway like NMI or Authorize.net through your merchant services provider, the processor is included. CloudFFL connects to the gateway, and the gateway handles the rest.

What CloudFFL Supports

CloudFFL integrates with two payment 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. The next page in this chapter covers the differences in detail to help you decide.