Payment gateway integration is the code that sits between your customer pressing “Pay” and money landing in your account – and it is the one part of a website where “mostly works” is not good enough. A missed webhook leaves a paid order marked unpaid, a badly handled 3-D Secure challenge loses the sale at the last step, and a careless form can drag your whole server into PCI DSS scope.
Contents
At CodeWiz we integrate Stripe, PayPal and regional bank processors into online stores, SaaS products, booking systems and custom applications. We build checkouts that handle Strong Customer Authentication properly, webhook handlers that never lose or double-process an event, subscription billing, refunds and reconciliation, and architectures that keep card data off your servers.
This service is for online stores adding or replacing payment methods, SaaS companies that need recurring billing, platforms and marketplaces that pay out to others, and businesses whose current integration produces mismatched orders, failed renewals or support tickets about payments that “went through but the order says unpaid”.
Stripe Integration Done Properly
Stripe is our default recommendation where it is available, mainly because of its API quality and documentation. Most Stripe problems we fix come from integrations built on outdated patterns or from treating the browser redirect as proof of payment.
Choosing the right Stripe building block
- Stripe Checkout: a hosted payment page – the fastest route to a compliant, conversion-tested checkout with wallets and local payment methods included.
- Payment Element: embedded payment fields on your own page, backed by the PaymentIntents API, for full control over design and flow.
- SetupIntents: saving a card for later or off-session charges, with authentication handled up front.
- Stripe Billing: subscriptions, trials, proration, invoices and the customer portal, instead of a home-made recurring billing cron.
- Stripe Connect: marketplaces and platforms that collect payments on behalf of sellers and split payouts.
Webhooks are the source of truth
The customer’s browser can close before the redirect back to your site, so an order must be marked paid from a verified webhook such as payment_intent.succeeded or checkout.session.completed, not from the success page. Our handlers verify the signature against the raw request body, ignore events they have already processed, hand the real work to a queue and answer quickly:
app.post('/webhooks/stripe', express.raw({ type: 'application/json' }), async (req, res) => {
let event;
try {
event = stripe.webhooks.constructEvent(
req.body, req.headers['stripe-signature'], process.env.STRIPE_WEBHOOK_SECRET
);
} catch (err) {
return res.status(400).send('Invalid signature');
}
if (await processedEvents.has(event.id)) return res.sendStatus(200);
if (event.type === 'payment_intent.succeeded') {
await queue.add('mark-order-paid', { intentId: event.data.object.id });
}
await processedEvents.add(event.id);
res.sendStatus(200);
});On the outgoing side we send an idempotency key with every create request, so a network retry never charges a customer twice. Locally we test the full flow with the Stripe CLI (stripe listen --forward-to) and Stripe’s test cards for 3-D Secure, declines and disputes. Stripe’s webhook documentation covers retries and event ordering in depth.
PayPal Setup and Integration
Many customers trust PayPal more than typing card details into an unfamiliar shop, and for cross-border sales it often lifts checkout completion. A modern PayPal integration looks very different from the old “Buy Now” buttons and IPN scripts that many sites still run.
- Orders API v2: the server creates and captures the order; the browser only renders the PayPal JavaScript SDK buttons. Amounts are always calculated on the server, never trusted from the client.
- Capture or authorize: immediate capture for digital goods, authorize-then-capture when you charge only after confirming stock or shipping.
- Card fields and Pay Later: where available for your account and country, PayPal’s card fields and Pay Later messaging can sit next to the PayPal button.
- Webhooks instead of IPN: PayPal webhooks verified through PayPal’s signature verification, handled with the same idempotent pattern as Stripe.
- Sandbox testing: separate buyer and seller sandbox accounts, including failed captures, refunds and disputes.
We also help with the business side: setting up the business account correctly, understanding currency conversion and payout timing, and knowing that new PayPal accounts can see funds held for a period – something to plan for before launch, not discover after. If you still run PayPal Standard with IPN, migrating to the REST APIs is usually a small, worthwhile project. The PayPal Checkout documentation describes the current integration options.
Multi-Gateway Support and Payment Routing
Relying on one payment provider is a single point of failure for revenue. A multi-gateway setup lets you offer the methods customers in each market expect, route transactions by currency or country, and keep selling when one provider has an outage or freezes an account.
How we design it
- One internal payment model: every gateway is an adapter behind a common interface, and every payment follows one state machine – pending, authorized, captured, partially refunded, refunded, disputed.
- Routing rules: choose a gateway by customer country, currency, amount or payment method, configurable without a deployment.
- Sensible failover: switch providers on technical errors and timeouts, never on a card decline – retrying a declined card on another gateway looks like fraud to issuers.
- Unified reporting: fees, refunds and payouts from all providers reconciled against orders in one place.
Payments in Bosnia and Herzegovina and the region
This matters especially in our region. Stripe does not onboard businesses registered in Bosnia and Herzegovina or Serbia, and PayPal’s receiving features vary by country. Local companies therefore often combine a bank processor – such as Monri, WSPay, CorvusPay or a bank’s Nestpay page – for domestic cards, and add PayPal or a company in a supported country for international customers. We integrate these hosted pages and their callbacks with the same rigour as Stripe, including signature checks on every response.
Payment Security and PCI DSS Compliance
PCI DSS (the Payment Card Industry Data Security Standard, currently version 4.0.1) applies to every business that accepts cards. How much of it applies to you depends almost entirely on how your integration is built – which makes architecture the cheapest compliance tool you have.
| Integration approach | Where card data is entered | Typical PCI DSS self-assessment | Checkout control |
|---|---|---|---|
| Hosted payment page (redirect) | Provider’s page | SAQ A | Limited branding |
| Embedded iframe fields (Payment Element, PayPal card fields) | Provider’s iframe on your page | SAQ A | High |
| Direct post / JavaScript-built form | Your page, sent straight to provider | SAQ A-EP | Full |
| Server-side API with raw card numbers | Your servers | SAQ D (full scope) | Full, at a high compliance cost |
Your acquirer or provider confirms which questionnaire applies, but the pattern is clear: we almost always build on hosted pages or iframe fields so raw card numbers never touch your infrastructure.
Strong Customer Authentication and 3-D Secure
Under PSD2 in the European Economic Area, most customer-initiated online card payments require Strong Customer Authentication, delivered through 3-D Secure 2. Done well, many payments pass through the frictionless flow without a challenge; authenticated payments also generally shift fraud chargeback liability to the card issuer. We make sure the integration supports challenges in a modal or redirect on mobile, applies exemptions (low-value, transaction risk analysis, merchant-initiated recurring payments) through the provider rather than by guesswork, and authenticates the first payment of a subscription so renewals can run off-session. Many acquirers outside the EEA, including in our region, require 3-D Secure as well.
Security measures around the checkout
- Card numbers and CVV codes are never logged or stored; we work only with provider tokens and payment IDs.
- API keys live in a secrets manager or environment configuration, with restricted keys that have only the permissions a service needs.
- A strict Content-Security-Policy and an inventory of scripts on payment pages – PCI DSS 4.0 put much more emphasis on controlling scripts there.
- Protection against card-testing attacks with rate limiting, bot challenges and provider fraud tools such as Stripe Radar. Our guide to API rate limiting explains the techniques.
- Payment data handled in line with GDPR: minimal personal data, clear retention and processor agreements.
Subscriptions, Refunds and Reconciliation
The first payment is the easy part. Ongoing revenue depends on what happens afterwards:
- Recurring billing: plans, trials, upgrades with proration, and dunning – smart retries plus emails asking customers to update an expired card, which recovers a meaningful share of failed renewals.
- Refunds and partial refunds triggered from your admin, synced back to the order, stock and accounting.
- Disputes: alerts when a chargeback arrives, with order, delivery and customer evidence collected automatically.
- Reconciliation: matching every payout to the orders, fees and refunds it contains, so finance is not doing it by hand in spreadsheets.
Behind all of this is the same principle: no payment event should ever be lost. Our article on zero data loss e-commerce explains how we make orders and payments recoverable even when something fails.
Common Payment Integration Mistakes We Fix
- Marking orders as paid on the return URL instead of a verified webhook.
- Webhook handlers that do slow work inline, time out and get retried, creating duplicate orders or emails.
- Accepting the amount or currency from the browser, which lets anyone pay one cent for an expensive order.
- Test and live API keys mixed up, or secret keys committed to Git.
- Charging saved cards off-session without an initial authenticated payment, so renewals fail with authentication errors.
- No alerting when payment failure rates spike, so a broken checkout goes unnoticed for days.
How We Work
- Discovery: we review your markets, currencies, payment methods, business model (one-off, subscription or marketplace) and existing integration.
- Plan: we recommend providers and an integration approach that minimizes PCI DSS scope, and define the payment state model and webhooks.
- Build: we implement checkout, webhooks, refunds, subscriptions and reconciliation, with secrets managed properly from day one.
- Test: we run every scenario in sandbox – 3-D Secure challenges, declines, timeouts, duplicate webhooks, refunds and disputes.
- Launch: we switch to live keys with a small real transaction, then monitor payment success rates and webhook delivery closely.
- Support: we keep up with API version changes and provider deprecations and add new payment methods as you grow.
Why CodeWiz
- Payments plus the whole stack: we build the stores, APIs and servers that payments plug into, so we fix problems end to end.
- Regional know-how: based in Banja Luka, we understand the payment options and limitations companies in Bosnia and Herzegovina and the region face.
- Security-minded by default: minimal PCI scope, verified webhooks and protected secrets are part of every integration, not an add-on.
- Tailored solutions: a hosted checkout when that is enough, a multi-gateway architecture when your business needs it.
- Fair pricing: premium development without premium prices – learn more about CodeWiz.
Frequently Asked Questions
Stripe or PayPal – which should I use?
Often both. Stripe is excellent for cards, wallets and subscriptions where it is available; PayPal adds a trusted option many shoppers prefer. Where Stripe is not available to your company, a local bank processor plus PayPal is a common combination. We recommend based on your markets and model.
How much does payment gateway integration cost?
Adding a hosted checkout to a supported platform is a small project. Custom checkouts, subscriptions, marketplaces or multi-gateway routing with reconciliation take considerably more work. Provider transaction fees are separate and paid to the provider. We estimate after reviewing your requirements.
Do I need to be PCI DSS compliant if I use Stripe or PayPal?
Yes, every merchant accepting cards has PCI DSS obligations, but with hosted pages or iframe fields they are usually limited to the short SAQ A questionnaire. Handling raw card data on your own servers would require far more extensive controls.
What is 3-D Secure and will it hurt my conversion?
3-D Secure is how the cardholder’s bank verifies a payment, for example with a banking app confirmation. With 3-D Secure 2, many low-risk payments are approved without a challenge, and in the EEA it is required for most online card payments anyway. A well-implemented flow keeps the extra step short.
Can you fix an existing integration that loses orders?
Yes. We audit how payments and orders are linked, add verified, idempotent webhook handling and reconciliation, and recover mismatched historical orders from the provider’s data where possible.
Ready to Make Payments Reliable?
Tell us where you sell, how you charge and what is not working today, and we will propose a payment setup that is secure and simple to operate. Contact us, read our earlier article on secure, scalable payment gateway integration, or see our payment gateway integration services.