Quick answer: Payment gateway integration connects your website to a provider such as Stripe, PayPal, Braintree, Square, Authorize.Net or Razorpay so you can take card and wallet payments. The safest approach for most custom sites is to let the gateway collect card details, either on a hosted payment page or with the provider’s embedded fields, so card numbers never touch your server. Then use webhooks to confirm payments and update orders. Plan for Strong Customer Authentication if you sell to European customers, handle refunds and failures, and test every path in the provider’s sandbox before going live.
What a payment gateway does
When a customer pays, several parties are involved: your website, the payment gateway, a payment processor, the card networks and the customer’s bank. The gateway is the part you integrate with. It securely accepts payment details, sends them for authorization and tells your site whether the payment succeeded.
Many modern providers bundle the gateway and merchant account, so you sign up once and start accepting payments. Others require a separate merchant account from a bank. For most small and mid-sized businesses, an all-in-one provider is simpler.
Choosing a provider
Compare providers on what matters for your business:
- Countries and currencies. Can it pay out to your bank and charge in your customers’ currencies?
- Payment methods. Cards, PayPal, Apple Pay, Google Pay, bank transfers, local methods such as UPI in India or iDEAL in the Netherlands.
- Pricing. Per-transaction fees, international card fees, currency conversion, chargeback fees and monthly charges.
- Developer experience. Clear documentation, client libraries for your language, a good sandbox and reliable webhooks.
- Recurring billing. If you sell subscriptions, check built-in support for plans, trials and failed payment retries.
- Payout timing. How long before funds reach your account.
- Support and dispute handling. What happens when a customer files a chargeback.
Some businesses offer two options, typically a card processor plus PayPal, because some customers prefer not to enter card details.
Hosted, embedded or direct: three integration styles
Hosted payment page
The customer is redirected to the provider’s page to pay, then returned to your site. Examples include PayPal’s checkout and Stripe Checkout.
Pros: fastest to build, smallest PCI burden, provider handles authentication flows and many payment methods. Cons: less control over design, a redirect that some customers find jarring.
Embedded fields
The payment form appears on your site, but the card fields are served by the provider in secure frames or through their JavaScript library. The card data goes straight to the provider, which returns a token your server uses to complete the payment.
Pros: checkout stays on your site with your styling, PCI scope stays relatively low. Cons: more development work, and your site must be served over HTTPS and kept secure because it hosts the payment page.
Direct API (server-side card handling)
Your server receives card numbers and sends them to the gateway.
Pros: total control. Cons: your systems are then fully in scope for PCI DSS, which means a demanding set of security requirements and assessments. Very few small businesses should take this route.
For most custom sites, embedded fields or a hosted page is the right choice.
PCI DSS in plain terms
Any business that accepts cards must follow the Payment Card Industry Data Security Standard. How much work that involves depends on how card data flows:
- With a fully hosted page or iframe-based fields, many merchants qualify for the shortest self-assessment questionnaire, often called SAQ A.
- With JavaScript-based embedded forms on your own pages, you may fall under a longer questionnaire, SAQ A-EP, because your site affects how the payment page is delivered.
- Handling card data on your server brings much heavier obligations.
Your provider will tell you which applies to their integration. Never store full card numbers or security codes yourself. If you need to charge a customer again, use the provider’s saved payment method or customer vault.
Strong Customer Authentication and 3D Secure
The EU’s revised Payment Services Directive (PSD2) introduced Strong Customer Authentication, which requires many online card payments in Europe to be verified with two factors, usually through 3D Secure. The rules came into force on 14 September 2019, with regulators allowing a phased enforcement period for card payments.
If you sell to customers in the European Economic Area, your integration should:
- Use your provider’s current APIs that support 3D Secure 2 and authentication challenges
- Handle the case where a payment requires extra customer action before it completes
- Use exemptions where allowed, such as low-value or merchant-initiated recurring payments, through the provider’s tools
- Save cards for future payments with proper authentication at setup
Older integrations that simply charge a card in one server call may start seeing declines for European cards. If you built your checkout several years ago, check with your provider whether it needs updating. Stripe, for example, introduced its Payment Intents approach to handle these flows.
Webhooks: confirming what actually happened
Do not rely only on the customer’s browser returning to a success page to mark an order paid. Browsers close, connections drop and redirects fail.
Instead, have the provider notify your server through webhooks: HTTP requests sent when events occur, such as payment succeeded, payment failed, refund issued or dispute opened.
Good webhook handling:
- Verify each webhook’s signature so attackers cannot fake a payment notice
- Make processing idempotent, so receiving the same event twice does not create two orders
- Respond quickly and queue heavy work
- Log events for troubleshooting
- Monitor for failures and retry gracefully
This is the same discipline we describe in building integrations that recover from API failures.
Connecting payments to the rest of your business
Taking money is only the start. Think about what should happen next:
- Send confirmation emails and receipts
- Update stock or booking availability
- Create invoices in your accounting software
- Sync customer and order data to your CRM
- Trigger fulfilment or notify staff, as in order notification automation
Planning these connections early saves manual work. Our guide to API integration covers the broader approach.
Refunds, failures and disputes
Your integration should cover more than the happy path:
- Declined payments. Show a clear, friendly message and let the customer try another method.
- Authentication required. Guide the customer through 3D Secure and resume the payment.
- Refunds. Allow staff to issue full or partial refunds from your admin, or document how to do it in the provider’s dashboard.
- Failed subscription payments. Retry, notify the customer and pause access if needed. Our article on payment reminder automation covers the follow-up side.
- Chargebacks. Know how you will be notified and what evidence you will provide.
Testing before you go live
Every major provider offers a sandbox or test mode with test card numbers that simulate successes, declines and authentication challenges. Test:
- Successful payment and order creation
- Declined card
- Payment requiring 3D Secure
- Customer closing the browser after paying (webhook should still update the order)
- Duplicate webhook delivery
- Full and partial refunds
- Currency and tax calculations
- Mobile checkout on real devices
Then switch to live keys, make a small real purchase, and refund it.
FAQ
Is a plugin enough for a WordPress or WooCommerce site?
Usually, yes. Official gateway plugins for WooCommerce handle most needs. Custom integration makes sense for custom applications, unusual pricing models or specific workflows.
How long does a custom payment integration take?
A hosted checkout can be working in days. A fully embedded checkout with subscriptions, webhooks and accounting sync can take several weeks, depending on scope.
Can I switch gateways later?
Yes, but saved cards and subscriptions may not move easily. Ask providers about data portability before you commit.
Do I need HTTPS?
Yes. Any page involved in checkout must be served over HTTPS, and in practice your whole site should be.
Get payments right the first time
A solid payment integration is mostly about sensible choices: let the provider handle card data, confirm payments with verified webhooks, plan for authentication and failures, and test thoroughly. If you want payments connected properly to your orders, invoices and follow-up, our Automate the busywork service can help.
