What happens when a customer clicks "pay" on your checkout page

A payment gateway is software that sits between your store and the banks involved in the transaction. When a customer enters their card details and clicks "pay," the gateway captures that information, encrypts it, and sends it to the payment processor—a separate company that talks to the customer's bank and your bank. The processor asks the customer's bank whether the card is real, whether the account has enough money, and whether the transaction matches the cardholder's known spending patterns. That answer comes back in seconds. If approved, the processor tells your gateway to show a success message. If declined, it tells your gateway why—insufficient funds, card expired, fraud suspected—and your customer sees that reason on screen.

The money does not move instantly. Your bank receives a settlement file from the processor, usually the next business day, and deposits the funds into your account. Until then, the transaction sits in a "pending" state. If a customer disputes the charge or requests a refund within that window, the processor can reverse it before the money ever reaches you. This delay is why refunds sometimes take a day or two to appear on a customer's statement, even though the gateway approved the transaction in seconds.

Key Takeaways

  • The gateway encrypts card details and routes them to the processor; it does not store the card information or move money itself.
  • The processor communicates with both banks in real time to approve or decline the transaction, usually within two to three seconds.
  • Settlement—the actual deposit to your account—happens the next business day or later, not at the moment of approval.
  • If a customer disputes a charge or requests a refund before settlement, the processor can reverse the transaction and you never receive the funds.
  • Different gateways charge different fees per transaction, and those fees are deducted from your settlement deposit.

The three parties that must communicate for a transaction to complete

Your payment gateway connects three separate entities: the customer's bank (the issuing bank), your bank (the acquiring bank), and the payment processor that sits between them. The processor is the traffic cop. It receives the encrypted card data from your gateway, validates the card number using the Luhn algorithm (a mathematical check that catches typos), and then sends an authorization request to the customer's bank through the card network—Visa, Mastercard, American Express, or Discover.

The customer's bank checks three things: Is this card active? Does this account have sufficient funds or available credit? Does this transaction look like fraud? If the answer to all three is yes, the bank sends back an authorization code. The processor receives that code, passes it to your gateway, and your gateway displays a success message to the customer. The entire exchange takes two to five seconds. If the bank declines—because the card is expired, the account is frozen, or the transaction triggers a fraud alert—the processor receives a decline code and your gateway shows an error message instead.

Your bank (the acquiring bank) is not part of this real-time conversation. It only receives a settlement file from the processor at the end of the day, listing all approved transactions. Your bank then deposits the total into your account, minus the processor's fee and any chargebacks or reversals that occurred since the previous settlement.

Why settlement takes longer than authorization

Authorization and settlement are two separate events, and this distinction matters when a customer asks for a refund or disputes a charge. Authorization means the customer's bank said yes—the card is real and the account has funds. Settlement means the money actually moved from the customer's bank to yours. A transaction can be authorized but never settle if the customer's bank reverses it, if you issue a refund, or if the customer disputes the charge before your bank processes the settlement file.

Most payment processors settle once per day, usually overnight. Your processor collects all approved transactions from the previous 24 hours, bundles them into a file, and sends that file to your bank. Your bank then processes the file and deposits the total into your account. This process typically completes by the next business day, though some processors offer faster settlement—same-day or even real-time—for an additional fee. Until settlement occurs, the transaction is "pending" on the customer's statement, and the funds are not yet in your account.

If a customer requests a refund or disputes a charge during this pending window, the processor can reverse the transaction before settlement. Your bank will never see the money, and the customer's bank will never debit their account. This is why refunds issued within 24 hours of purchase often appear on a customer's statement within one or two business days—the processor reverses the transaction before settlement happens. Refunds issued after settlement takes longer because your bank must send a separate credit back to the customer's bank, which then posts it to the customer's account.

How the gateway protects card data and prevents fraud

Your payment gateway encrypts card details the moment the customer enters them, using a security standard called PCI DSS (Payment Card Industry Data Security Standard). This encryption means your gateway receives the card number in an unreadable format and immediately passes it to the processor. Your gateway does not store the card number, and neither does your web server. Only the processor stores it, in a secure vault, and only if the customer consents to saving the card for future purchases.

The processor also runs fraud checks in real time. It compares the transaction amount, the customer's location, the merchant category (what you sell), and the card's known spending patterns against millions of historical transactions. If the transaction looks suspicious—a $5,000 purchase from a card that normally buys $50 items, or a purchase from a country the cardholder has never visited—the processor can decline it automatically or flag it for manual review. Some processors let you set your own fraud rules: decline all transactions over a certain amount, decline transactions from certain countries, or require additional verification (like a one-time password) for high-risk purchases.

Your gateway also supports tokenization, which lets customers save their card for future purchases without you ever seeing the full card number. The processor issues a token—a random string of characters—that represents the card. On the next purchase, the customer's browser sends the token instead of the card number. The processor decrypts the token, retrieves the card details from its vault, and processes the transaction. This reduces your fraud risk and simplifies the checkout experience for repeat customers.

What happens when a transaction is declined or fails

When a customer's bank declines a transaction, the processor receives a decline code that explains why. Common codes include "insufficient funds," "card expired," "lost or stolen card," "transaction not permitted," and "suspected fraud." Your gateway displays this code to the customer, usually in plain language: "Your card was declined. Please check the expiration date and try again." The customer can then update their card details and retry, or choose a different payment method.

A failed transaction is different from a declined one. A failure means the communication between your gateway and the processor broke down—a network timeout, a server error, or a malformed request. When this happens, the processor may not have received the authorization request at all, or it may have received the request but failed to send back a response. Your gateway cannot know whether the transaction was approved or declined. Some gateways handle this by showing an error message and asking the customer to try again. Others retry automatically. The risk is that the customer's bank may have approved the transaction, but your gateway never received the approval code, so it shows an error and the customer retries. This can result in a duplicate charge.

To prevent duplicates, most gateways use an idempotency key—a unique identifier for each transaction attempt. If the customer retries and the gateway sends the same idempotency key, the processor recognizes it as a retry of the same transaction and does not process it twice. The processor returns the original authorization code, and your gateway shows a success message. This is why it is safe to retry a failed transaction: the processor will not charge the customer twice.

How fees are deducted and when you see them on your statement

Payment processors charge fees in two ways: per-transaction fees and monthly fees. A per-transaction fee is usually 2.2% to 3.5% of the transaction amount plus a flat fee of $0.20 to $0.50. So a $100 transaction might cost you $2.50 to $3.50. Some processors charge a monthly fee instead of per-transaction fees, or both. Monthly fees range from $10 to $300 depending on your transaction volume and the features you use.

These fees are deducted from your settlement deposit. If you process $10,000 in transactions and your fee rate is 2.9% plus $0.30 per transaction, and you have 100 transactions, your fees total $290 (2.9% of $10,000) plus $30 (100 × $0.30) = $320. Your bank deposits $9,680 into your account, not $10,000. You see the full $10,000 listed as "gross volume" on your processor's statement, and the $320 listed as "fees," with $9,680 shown as "net deposit."

Chargebacks and refunds also reduce your settlement. If a customer disputes a charge and the processor rules in the customer's favor, the processor deducts that amount from your next settlement deposit. If you issue a refund, the processor deducts it as well. This is why your settlement deposit can vary significantly from day to day, even if your transaction volume is steady.

The difference between hosted payment pages and embedded forms

Your gateway can handle card data in two ways: a hosted payment page or an embedded form. A hosted payment page is a page that the processor controls, not you. When a customer clicks "pay," your store redirects them to the processor's website. The customer enters their card details on the processor's page, and the processor handles the encryption and fraud checks. Then the processor redirects the customer back to your store with a success or failure message. You never see the card details, and your store never handles the encryption. This is the simplest setup and requires the least security work on your end.

An embedded form is a form that lives on your checkout page but is powered by the processor's code. The customer enters their card details into a field that looks like part of your store, but the processor's JavaScript code intercepts the data before it reaches your server. The data is encrypted on the customer's browser and sent directly to the processor. Your server never touches the card number. This approach gives you more control over the checkout experience—you can style the form to match your store—but it requires more technical setup and puts more responsibility on you to maintain security.

Both approaches are PCI-compliant if set up correctly. The key difference is control: hosted pages are simpler but less customizable; embedded forms are more work but give you a seamless checkout experience.

Frequently Asked Questions

Why does my customer's bank statement show a pending charge for days after I issued a refund?

The refund reverses the original transaction, but the customer's bank may not process the reversal immediately. The processor sends the reversal to the customer's bank, which then removes the pending charge from the customer's statement. This usually takes one to three business days. If the original transaction had already settled before you issued the refund, the reversal takes longer because it is a separate credit transaction, not a cancellation of the original charge.

What should I do if a customer says they were charged twice?

Check your processor's dashboard to see if two transactions appear for that customer. If yes, one is likely a retry of a failed transaction. The processor should have used an idempotency key to prevent the duplicate, but occasionally the key fails. Contact your processor and ask them to reverse the duplicate charge. If only one transaction appears in your processor's dashboard but the customer sees two charges on their statement, the duplicate may be a pending charge that will disappear within a few days, or it may be a separate transaction from a different merchant.

Can I see which transactions will settle tomorrow?

Yes. Your processor's dashboard shows a settlement report that lists all transactions approved since the last settlement and their status. Transactions marked "pending settlement" will be included in tomorrow's deposit. Transactions marked "settled" have already been deposited. You can also see refunds, chargebacks, and fees in this report, so you can predict what your net deposit will be.

What happens if my processor goes out of business?

Your funds in settlement are protected by the processor's acquiring bank, not by the processor itself. If the processor fails, your bank continues to process settlements normally because the bank is the entity that actually holds your money. However, you will need to switch to a new processor for future transactions. Your old processor's dashboard will become unavailable, so download your transaction history before that happens.

Do I need a different gateway for each payment method I accept?

No. Most gateways support credit cards, debit cards, digital wallets (Apple Pay, Google Pay), and sometimes bank transfers or buy-now-pay-later services. You choose which methods to enable in your gateway's settings. Each method may have a different fee rate, so check your processor's pricing before enabling a new method.