What Is a Payment Gateway? How Online Payments Work, Explained
A payment gateway securely passes card details from your checkout to the banks and back. How online payments work, what they cost, and what to ask your AI.
Mythex Team · · 6 min read
A payment gateway is the service that securely takes a customer's payment details at checkout, passes them to the banks and card networks for approval, and sends back "approved" or "declined" — usually within a few seconds. It's the bridge between your app and the financial system. Stripe, PayPal, Adyen, Square and Braintree are well-known examples.
Today most of these companies bundle the gateway with everything else you need to get paid, so "payment gateway," "payment processor" and "payment provider" are often used to mean the same thing.
Why payment gateways matter when you build with AI
"Add payments" is one of the most common requests people make to AI builders, and one of the easiest to get subtly wrong. The code itself is usually short. The important parts are the decisions around it:
- Which provider fits your business, country and what you sell.
- Where the code runs. Secret payment keys must stay on the server, never in the browser.
- How your app learns a payment succeeded. The reliable way is a webhook from the provider — not the customer landing on a "thank you" page.
- Your legal and tax responsibilities, which depend on who is the merchant of record.
Understanding what a gateway does helps you give clear instructions and check that the result is safe.
An everyday analogy
Think of paying by card in a shop.
The card terminal on the counter is the gateway: it reads your card securely and sends the request off. It doesn't decide anything — it passes the question "can this person pay €40?" along a chain to your bank and gets the answer back. The shop's bank (acquirer) and your bank (issuer) do the deciding, via the card network (Visa, Mastercard) that connects them.
An online payment gateway is that terminal, rebuilt for the web — plus the security to handle card details that arrive over the internet.
How an online card payment works
Here's what happens in the few seconds after a customer clicks "Pay":
| Step | What happens | Who does it |
|---|---|---|
| 1. Checkout | Customer enters card details on a secure payment form | The payment provider's form or page |
| 2. Encryption | Details are encrypted and sent to the gateway | Gateway |
| 3. Authorisation request | The request travels to the card network and the customer's bank | Processor, card network |
| 4. Checks | The bank checks funds and fraud signals, and may ask for extra verification such as 3D Secure | Issuing bank |
| 5. Response | Approved or declined comes back to your app | Gateway |
| 6. Capture and settlement | The money is collected and, after the provider's payout schedule, paid into your bank account minus fees | Processor, acquirer |
Two points are worth knowing:
- Authorisation isn't the same as being paid. Money is reserved first, then captured, then settled to your account — often days later.
- Your app shouldn't see the card number at all. Modern providers give you a hosted checkout page or embedded fields they control, and your app only gets a reference to the payment.
The main pieces, and who handles them
| Piece | What it is |
|---|---|
| Payment gateway | Securely captures payment details and passes them on. |
| Payment processor | Moves the transaction data between the banks. |
| Merchant account | The account that receives card payments on your behalf. Bundled by providers like Stripe. |
| Acquirer | The bank on the merchant's side. |
| Issuer | The customer's bank, which approves or declines. |
| Card network | Visa, Mastercard and others, connecting acquirers and issuers. |
| Merchant of record | The business legally selling to the customer and responsible for tax, refunds and disputes. |
Some providers (Paddle, Lemon Squeezy) act as the merchant of record themselves, handling sales tax and VAT for you in exchange for higher fees. Others (Stripe, PayPal) leave you as the merchant of record, with optional tax tools. For a fair look at the options, see Stripe vs Paddle vs Lemon Squeezy and Stripe vs PayPal.
A worked example: selling a course
You sell an online course for €99 and ask your AI builder to add a "Buy" button.
- Customer clicks Buy. Your server uses its secret key to ask the provider to create a checkout session for €99 and gets back a link.
- The customer is sent to the provider's hosted checkout page, enters their card, and completes any 3D Secure check with their bank.
- The payment is approved, and the customer is redirected to your "success" page.
- Separately, the provider sends a webhook to your server: "payment for session X succeeded." Your server checks the webhook's signature, finds the order, marks it paid and unlocks the course.
- Days later, the money minus fees lands in your bank account.
Step 4 matters most. If you unlocked the course on the success page instead, anyone who found that URL could get it free, and customers whose browser closed early would pay and get nothing.
Key terms
| Term | Meaning |
|---|---|
| Checkout session | A one-off payment page or flow created by your server for a specific purchase. |
| Test mode | A sandbox where you use test keys and test card numbers — no real money moves. |
| Publishable / secret key | The publishable key can appear in browser code; the secret key must stay on the server. |
| 3D Secure | An extra step where the customer confirms the payment with their bank, common in Europe under Strong Customer Authentication (SCA) rules. |
| PCI DSS | The card industry's security standard for anyone handling card data. |
| Chargeback | When a customer disputes a payment with their bank and the money is pulled back. |
| Refund | Money returned by you, voluntarily. |
| Payout | The provider transferring your collected money to your bank account. |
Common misconceptions
- "I have to store card numbers to charge customers again." No. Providers store the card and give you a reference token for repeat charges and subscriptions. You should never store card numbers yourself.
- "The success page means the payment worked." Confirm payments with webhooks on the server. Redirects can be skipped, faked or never happen.
- "Payment providers all cost about the same." Fees vary by provider, country, card type and whether tax handling is included. Check each provider's current pricing page for your country.
- "Using Stripe makes me PCI compliant." It makes compliance much simpler, because card data stays with the provider — but you still have a (usually short) self-assessment to complete.
- "Test mode and live mode behave identically." They're close, but live mode needs a fully verified account, real webhook endpoints set up for the live environment, and real bank details.
- "A payment gateway handles my taxes." Only if it's the merchant of record or you turn on and configure its tax features. Check your local rules or ask an adviser.
What to ask your AI builder
- "Add [Stripe] Checkout for [product]. Create the session on the server using the secret key from an environment variable."
- "Only mark orders as paid from a verified webhook, and check the webhook signature."
- "Handle the webhook being sent twice without creating duplicate orders."
- "Use test mode keys and walk me through testing with the provider's test cards, including a declined card."
- "What happens if the customer closes the tab after paying?"
- "Show me every place a payment key is used, and confirm the secret key never reaches the browser."
Payment gateways in Mythex
Mythex doesn't include built-in payments for the apps you build, and there's no one-click "Connect Stripe." You create an account with your chosen provider, add its test keys as project secrets, and ask the agent to build the checkout on the server side. Test in Preview with the provider's test cards, then publish. The docs walk through this in Accept payments with Stripe, and Webhooks covers the confirmation step.
For a step-by-step build, see how to add payments to your app and, for recurring billing, how to add subscriptions with Stripe.
Questions
What is a payment gateway in simple terms?
A payment gateway is the service that securely takes a customer's payment details from your checkout, sends them to the banks and card networks for approval, and returns an approved or declined answer to your app — usually in a few seconds.
What is the difference between a payment gateway and a payment processor?
Strictly, the gateway is the secure front door that captures and passes on payment details, and the processor moves the transaction between the banks. In practice, modern providers like Stripe, PayPal and Adyen bundle both, plus the merchant account, into one service, so the terms are often used interchangeably.
Do I need to be PCI compliant to accept card payments?
Any business that accepts cards must meet the PCI DSS security standard in some form. Using a hosted checkout page or the provider's embedded payment fields means card numbers never touch your servers, which greatly reduces what you're responsible for. Your provider will tell you which self-assessment applies.
What is a merchant of record?
A merchant of record is the business legally selling to the customer, responsible for things like collecting and paying sales tax or VAT, and handling refunds and chargebacks. Services like Paddle and Lemon Squeezy act as merchant of record for you; with Stripe or PayPal, you usually are.
Can I add payments to an app built with AI?
Yes. An AI builder can write the code that connects your app to a provider like Stripe: creating checkout sessions on the server, handling webhooks and updating orders. You still need your own account with the provider, and you should test everything in its test mode before going live.