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 pays by card — whether in person, over the phone, or on your website — the payment goes through three steps:

1. Authorization — The payment processor asks the customer's bank: "Is this card valid, and does the customer have enough money?" The bank says yes or no. If yes, the funds are put on hold. Think of it like opening a bar tab — the money is reserved but hasn't actually moved yet.
2. Capture — This is when you actually charge the card. In most cases, this happens automatically right after authorization. For special orders or layaway, you might authorize now and capture later once the item arrives.
3. Settlement — At the end of the day, all captured transactions are batched together and sent to the bank for final processing. The money moves from the customer's bank to your merchant account. This usually takes 1–2 business days.

Card-Present vs Card-Not-Present

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

• Card-present — The customer is at your counter and inserts, taps, or swipes their physical card on a terminal. Example: a customer buying a Glock 19 at the register. These transactions are more secure (the chip proves the card is real) and typically have lower processing fees.
• Card-not-present — The card number is typed in manually — either by you (phone order) or by the customer (online purchase). Example: a customer calls in to pre-pay for a special-order suppressor, or places an order on your website. These transactions carry slightly higher fees because there's no physical card to verify.

Tokenization — Why Card Numbers Are Never Stored

When a customer pays by card in CloudFFL, their actual card number is never stored in your system. Instead, the payment processor replaces the card number with a random code called a token. This token can be used to charge the same card again (for future orders or refunds) but is worthless to anyone who might steal it.

This is why you'll sometimes see a returning customer's card listed as something like "Visa ending in 4242" — CloudFFL only knows the last four digits and the token, not the full number. This keeps you PCI-compliant and protects your customers.

Payment Gateway vs Payment Processor

You'll sometimes hear these two terms used interchangeably, but they mean slightly different things:

• Payment gateway — The technology that securely sends card details from your system to the processor. Think of it as the secure tunnel between CloudFFL and the bank. NMI and Authorize.net are both payment gateways.
• Payment processor — The company that actually moves the money between banks. Your gateway talks to the processor behind the scenes.

As a dealer, you don't need to worry much about this distinction. Just know that CloudFFL connects to your gateway (NMI or Authorize.net), and the gateway handles everything else.

CloudFFL's Supported Payment Gateways

CloudFFL supports two payment gateways. You can use one or both, depending on your needs:

• 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 page, NMI vs Authorize.net — Choosing Your Provider, for a detailed comparison to help you decide which one (or both) to set up.