How online card payments work: best practices explained

Every time a customer swipes a card on your checkout page, a cascade of systems spring into motion—tokenization, routing, authorization, and settlement all happen in seconds. Understanding how online card payments work: best practices explained is essential for building reliable payment systems and troubleshooting when things go wrong. We'll walk through each stage of the payment journey, show you what happens behind the scenes, and highlight the practical decisions that keep payments flowing.

The flow: multiple parties, one transaction

A card payment isn't a direct line between customer and your bank. Instead, it's a choreographed handoff across at least four distinct parties, each with their own role. When a customer enters card details during checkout, that data travels through a payment processor (like Stripe), gets routed by the card network (Visa, Mastercard), reaches the customer's issuing bank, and eventually settles into your merchant account. Each hop adds layers of security, fraud detection, and compliance checks.

Here's what happens in sequence:

1. Customer enters card details. On your checkout page, sensitive data like PAN (Primary Account Number), expiry, and CVV are captured.
2. Payment processor tokenizes the card. Stripe or your processor replaces the raw card data with a unique token, keeping sensitive information secure.
3. Card network routes the request. Visa or Mastercard receives the authorization request and forwards it to the right issuing bank.
4. Issuing bank approves or declines. The bank checks for fraud, available funds, and account status, then returns a response.
5. Funds settle to your account later. After authorization, the actual money transfer happens asynchronously over the next 1-3 business days.

The entire authorization loop typically completes in 1-2 seconds, but settlement can take much longer. This temporal gap is crucial to understand: when you show a customer a "payment successful" message, their bank has only promised to transfer funds—the money hasn't landed in your account yet.

Authorization: the bank reserves funds

Authorization is when the issuing bank checks whether the customer has sufficient funds and approves the transaction. At this stage, the bank doesn't actually move money—it reserves (or "holds") the amount on the customer's account. Think of it like a restaurant putting a hold on your card when you order; the money is earmarked but not yet charged.

When you call the authorization endpoint, you're asking the bank a simple question: "Can this payment go through?" The bank responds with an authorization code if approved, or a decline reason if not. Common decline codes include:

• Insufficient funds — The account balance is too low.
• Lost or stolen card — The card is flagged in the issuer's system.
• Incorrect CVV — The security code doesn't match.
• Expired card — The expiry date has passed.
• Fraud detected — The bank's ML models flag suspicious activity.

Here's a simplified example of how you'd initiate an authorization with Stripe:

const stripe = require('stripe')('sk_test_...');

const paymentIntent = await stripe.paymentIntents.create({
  amount: 2999, // $29.99 in cents
  currency: 'usd',
  payment_method: 'pm_card_visa',
  confirm: true,
  capture_method: 'manual', // Auth only, don't capture yet
});

console.log(paymentIntent.status); // 'succeeded' or 'requires_action'
console.log(paymentIntent.charges.data[0].id); // Authorization code equivalent

By setting capture_method: 'manual', you're telling the processor: "Authorize the funds but don't capture them yet." This is useful for scenarios like marketplace orders or subscription sign-ups where you want to confirm the payment works before actually claiming the money.

Authorization holds typically expire after 7-10 days if not captured. If a customer's bank is particularly strict or if fraud is suspected, they may decline the authorization even if funds are available. This is where retry logic and fallback payment methods become important.

Capture: you claim the reserved funds

Once authorization succeeds, the funds are reserved. Capture is the step where you actually claim those funds and tell the bank to pull them from the customer's account. Without capture, an authorization is just a promise—no money moves.

In many e-commerce flows, authorization and capture happen instantly (auto-capture). But in others—like two-sided marketplaces or high-value transactions—you want to separate them. For example, you might authorize payment immediately when an order is placed, but only capture it after the order ships and the customer receives their goods.

Capturing with Stripe is straightforward:

// First, authorize without capturing
const paymentIntent = await stripe.paymentIntents.create({
  amount: 5000, // $50.00
  currency: 'usd',
  payment_method: token,
  confirm: true,
  capture_method: 'manual',
});

// Later, when the order ships
const captured = await stripe.paymentIntents.confirm(paymentIntent.id, {
  // Confirm triggers capture if not yet captured
});

console.log(captured.status); // 'succeeded'

Key insight: if you never capture an authorization, the customer's bank eventually releases the hold and the funds return to their account. This can happen anywhere from 7 to 30 days depending on the issuer. From a customer support perspective, this means if an order gets cancelled, you should void the authorization rather than waiting for it to expire naturally.

Partial captures are also possible—if a customer orders ten items but only eight ship, you can capture only the amount for those eight items. This keeps your payment flow aligned with actual fulfillment, reducing chargebacks and disputes.

Settlement: money arrives in your bank

Settlement is the behind-the-scenes financial process where captured funds actually move from the customer's bank to your merchant account. This is where "business days" matter. Even though authorization and capture happen in milliseconds, settlement takes 1-3 business days on average (sometimes longer for international cards or specific card networks).

Here's what happens during settlement:

1. Your processor batches all captured transactions from the day.
2. The card network aggregates payments across all merchants.
3. Issuing banks process the mass debit and send funds to acquiring banks.
4. Your acquiring bank credits your merchant account.
5. You see the funds in your actual bank account.

This delay exists partly for operational reasons (batch processing is cheaper) and partly for dispute handling (the network needs time to handle chargebacks before final settlement). Some payment processors offer faster settlement for an additional fee, but most businesses accept the standard 1-3 day window.

From a reconciliation perspective, you should track three key dates for every transaction:

• Transaction date — When the customer completed the payment.
• Capture date — When you claimed the funds (often the same as transaction date).
• Settlement date — When money arrived in your account.

Reconciling your Stripe dashboard against your bank statement requires matching these dates carefully, especially if you're doing partial captures or refunds:

// Fetch all charges settled on a specific date
const charges = await stripe.charges.list({
  created: {
    gte: Math.floor(new Date('2024-01-15').getTime() / 1000),
    lt: Math.floor(new Date('2024-01-16').getTime() / 1000),
  },
});

const totalSettled = charges.data
  .filter(c => c.paid && !c.refunded)
  .reduce((sum, c) => sum + c.amount, 0);

console.log(`Total settled: $${(totalSettled / 100).toFixed(2)}`);

Common mistakes

Assuming capture = money in bank. Many teams launch with the assumption that as soon as a capture succeeds, funds are available. Settlement delays catch them off guard during cash flow planning. Budget for 2-3 days of float between capture and settlement.

Not storing authorization codes. If a customer disputes a charge, you need proof that the authorization succeeded. Always log the authorization ID, response code, and timestamp. This becomes critical during chargeback investigations.

Forgetting to handle failed captures. A capture can fail even if authorization succeeded (for example, if the bank becomes unavailable during settlement). You need retry logic and manual review workflows for failed captures.

Mixing authorization and capture in your order workflow. If your code assumes every successful authorization means the payment is captured, you'll create orphaned authorizations that confuse customers and your reconciliation process. Be explicit about when capture happens.

Not monitoring settlement delays. Occasionally a transaction authorizes and captures but fails to settle. Set up alerts if settlement takes longer than 4 days. Investigate and escalate to your processor if needed.

Key takeaways

• Card payments involve four parties minimum: customer, processor, card network, and issuing bank. Each adds latency and potential failure points.
• Authorization reserves funds but doesn't move money. Capture claims the funds. Settlement moves the actual money to your account days later.
• Separating authorization and capture gives you flexibility for marketplace, subscription, and high-value transaction workflows.
• Settlement takes 1-3 business days; plan your cash flow accordingly and always reconcile transaction dates with settlement dates.
• Log authorization codes, capture timestamps, and settlement status. This data becomes invaluable during disputes and chargebacks.
• Handle failed captures gracefully with retry logic and manual escalation paths. Network timeouts happen; your code shouldn't assume every capture succeeds.