How payment integration actually works — a plain explanation for business owners

Once a "Pay by card" button goes live on the site, most business owners consider the job done — money comes in, orders appear, so the integration must be working. The gap shows up on the first bad day: a customer messages saying the money left their card but no order appeared, or the monthly payout is smaller than expected. That's when nobody knows who to call — the team who built the site, the payment provider, or the bank.

The reason is that payment integration isn't one button — it's a chain that passes information between at least three separate parties. If you don't know where that chain can break, each party points at the next one. What follows isn't code, it's the plain version: what actually happens the moment someone orders, when the money reaches your account, and how to tell whose job it is when something breaks.

From checkout to money in your account

Between the moment a customer clicks "Pay" and the moment the money shows up on your account, three separate steps happen — and a different party owns each one.

1. The order is created on your site, but the card number never touches it

When a customer confirms their cart, your site does exactly one thing: it hands the provider the order amount and reference number. The card number, expiry date and CVV never reach your site at all — the customer enters them on the provider's own secure page or widget. That isn't a design preference; keeping card data off your own server measurably shrinks your PCI DSS compliance burden. Businesses that integrate through a provider's hosted checkout or embedded elements get a lighter compliance questionnaire, because the sensitive data never touches their infrastructure in the first place (Stripe's own security documentation). If a developer proposes building your own card form for a "more on-brand" look, that trade shifts the entire compliance burden onto you.

2. The bank confirms, not the site

Whether a payment succeeds is decided by the customer's own card-issuing bank, not by your website. That's what 3-D Secure is for — the bank may ask the customer for an SMS code, an app confirmation, or a fingerprint. The point of that extra step is to stop fraud on card-not-present purchases and confirm the card is genuinely being used by its owner (EMVCo's own explanation). So when a customer sees "payment declined," it's usually the bank's call, not a broken checkout — it just shows up on your screen, so your site gets blamed for it.

3. The result arrives as a notification, not a return page

After paying, the customer is normally redirected back to your site to see a "thank you" page. In a properly built system, though, that page isn't the real confirmation — the customer can close the tab, lose signal, or leave the app before it even loads. The real confirmation arrives separately, in the background, as a notification the provider sends your system — usually called a webhook. Why that notification matters so much is the next section.

"I paid but the order isn't showing" — the real reason

This is the most common complaint: the customer's card was charged, but the order sits "pending" in your dashboard, or never appears at all. The first instinct is to blame the website, but the fault usually sits somewhere else.

As covered above, the provider reports the payment result through a background notification. If your system misses that notification even once — a server briefly down, a network hiccup — and the provider doesn't retry sending it, the payment can succeed cleanly on the bank's side while your system never finds out. The result: the money is gone, there's no order, and support ends up stuck between two parties who each say it's the other one's problem.

Ask this before launch, not after the first incident — how many times does the provider retry a failed notification, and does your own system log and check for those notifications rather than trusting the browser redirect alone. It's a deliberate step in how PixelLabs builds this: a failed notification isn't dropped, it triggers an automatic retry — because one undelivered notification is one lost order.

Payment integration isn't a button — it's a chain of trust between three parties, and the weakest link is usually not in the code but in nobody having written down who owns what.

When the money actually reaches your account

Many owners picture a card payment like a cash register — the customer pays, the money is instantly in the account. It doesn't work that way.

The amount the customer pays lands in the provider's own account first; the provider deducts its fee, then transfers the rest to your bank account on an agreed schedule. That settlement step is entirely separate from the "payment successful" message the customer sees on your site — for the customer the transaction is over in a second, while for you the actual transfer of money is only just starting.

Get that schedule and fee percentage written into the contract before the integration goes live, not discovered on the first monthly statement. Transparency here follows the same rule we hold ourselves to: the service fee and the transaction fee belong on two separate lines, never blended into one number with a hidden markup.

Who should be holding the card data

Sometimes a team suggests collecting the card number directly on your own form — "to make it faster" or "to match the brand."

It's technically possible, but it has a cost — the moment a card number passes through your own server, you inherit the full weight of the financial industry's strictest security audit (PCI DSS): annual assessment, encryption, access control, and more. Use the provider's hosted page or widget instead, and most of that burden stays on their side.

For a small or mid-sized business, the right call is almost always the same one — use the provider's ready-made checkout rather than commissioning your own card form. The loss in brand polish is small; the risk isn't.

Whose door to knock on when it breaks

A payment fails, you call support, your agency says "everything's fine on our end," the provider says "the bank declined it," and the bank won't talk to you at all.

Each of the three parties owns a specific slice. An error before the order is even created — the page won't load, the button doesn't respond — is your site's technical problem. "Declined" showing on the provider's page is the bank's decision, usually tied to balance, limits, or a failed 3-D Secure check. A notification that never arrives at all is a reliability gap in the integration itself, and that one belongs to whoever built it, because catching and retrying it is exactly what the integration is supposed to do.

Before the integration goes live, write down who owns which of these three zones — who watches the site side, who watches the provider side, and what the provider's real support channel actually is (a person you can reach, not just a form). Skip that step and every failure turns into a multi-day investigation.

Payment integration isn't something you wire up once and forget. If the order-notification-settlement chain isn't planned properly, the same question resurfaces with every change — a new provider, a new courier, a move to 1C. Our system integration service exists to wire that whole chain — payments, delivery, SMS and accounting — together, with automatic retries built in so a failed notification never turns into a lost order.