If you’re building a fintech product, one of the key questions you’ll face is: how can we make online payments as smooth, secure, and scalable as possible? One potential answer is to create your own payment gateway tailored to a popular CMS.
This component sits at the heart of how your service connects with online stores — helping you manage the user experience, onboard clients quickly, and build trust in your product. But behind the familiar “Pay now” button lies a complex setup: APIs, integration scenarios, security standards, CMS compatibility, and regional regulations.
In this guide, we’ll break it all down: where to start, what to consider, and how to build a system that drives your business forward.
What is a payment gateway?
A payment gateway is the link between your website or app and the acquiring bank that processes payments. When a customer enters their card details, the gateway encrypts the data, validates it, and sends a request to the acquiring bank.
The acquiring bank — the institution that handles payments for merchants — then approves or declines the transaction. The gateway receives the bank’s response and passes it back to your platform.
Importantly, the gateway doesn’t store or manage funds, it simply ensures secure transmission of sensitive data. This differentiates it from payment processors, which handle settlement and clearing.
To better understand how a payment gateway works, here’s a simplified flow:
- The customer enters their payment details and initiates checkout.
- The website sends the payment data to the gateway.
- The gateway encrypts and validates the request, then forwards it to the acquiring bank.
- The bank approves or declines the payment and sends a response back to the gateway.
- The gateway relays the response to the website and customer.
Why fintech startups should create their own payment gateway
A payment service succeeds when it’s easy to use. For a fintech provider, that means the easier it is for merchants to connect, the more clients you’ll attract.
If you only offer a raw API, store owners have to hire developers, study your documentation, and spend time integrating. Many never make it that far.
A ready-to-use custom payment gateway changes the game. It:
- Lowers the entry barrier — a merchant installs your plugin and starts accepting payments right away.
- Sets you apart from competitors who don’t offer turnkey integrations.
- Puts you in control of quality — you own the infrastructure, fix issues quickly, and roll out new features on your terms.
- Simplifies updates and support — all stores use the same integration.
- Accelerates growth — it’s easier to expand to new countries and platforms when you own the experience end-to-end.
Designing the API
Your API is what enables stores to interact with your payment infrastructure — from processing payments to checking statuses and handling refunds. If you’re building a payment module, designing the API early is essential. It defines how easily partners will be able to integrate with your product.
The API contains built-in methods that essentially act as commands. These commands let external systems (like eCommerce stores) “talk” to your payment gateway. Each method handles a specific task such as creating a transaction, issuing a refund, or checking a payment’s status.
The clearer and more stable these methods are, the easier integration becomes, and the fewer issues your partners will face.
Here are the core methods typically included in a payment gateway API:
create_payment— creates a payment session.
Called when a customer places an order. Returns a payment page URL or a payment token.
Example: The store sends the amount, currency, andreturn_url, receives the link, and redirects the buyer there.get_payment_status— checks the payment status.
Used to retrieve the current transaction state: paid, declined, pending, etc.
Example: After the customer returns to the site, the store calls this method to update the order.refund_payment— initiates a refund.
Called by the store or provider to return funds to the customer. Can be a full or partial refund.
Example: A customer cancels the order, and the store initiates the refund via API.get_payment_methods— lists available payment options.
Returns the set of methods available to that store or region — cards, Apple Pay, installments, and so on.
Example: The store dynamically shows available options at checkout.webhook_listener(orcallback_url) — listens for gateway notifications.
This isn’t a method you call, but an endpoint that receives updates from the payment system.
Example: After a successful payment, the gateway sends a POST request with the payment status, and the store updates the order accordingly.
If you’re unsure which methods your API should include or how to document them — we can help. We’ll advise you on what to include and how to design an API that makes payment gateway integration smooth for your partners.
Choosing the integration method: redirect vs. embedded form
There are two main ways to integrate a payment gateway into an online store:
Redirect
When the buyer clicks “Pay,” they’re taken to your hosted payment page. This approach is secure and easy to maintain: the store doesn’t handle card data, doesn’t need PCI DSS compliance, and all updates are managed in one place — your payment page.
In a redirect flow, Apple Pay and Google Pay buttons appear on your side, on the hosted checkout page. That makes things simpler for merchants: they don’t need to modify their own site, and you handle all SDK integration.
Downside: the customer is taken off-site, which can reduce conversion if they don’t return to complete the payment.
Embedded Form
In this scenario, payment fields are embedded directly on the store’s checkout page. The customer stays on the site throughout the entire process — which improves UX and usually results in higher conversion, especially if you add Apple Pay or Google Pay buttons to the checkout.
To support this, your plugin must properly integrate these buttons into the checkout flow by:
- showing them only on compatible devices and supported browsers (e.g., Apple Pay on Safari for iOS/macOS),
- following Apple and Google’s visual and UX guidelines,
- avoiding conflicts with other buttons or checkout logic,
- hiding buttons automatically when the payment method is unavailable.
It also needs to handle the payment tokens returned by Apple Pay and Google Pay — and securely pass those tokens into your API to finalize the transaction.
Downside: this approach requires more development effort. Your team needs to handle tokens instead of raw card data, implement encryption, comply with PCI DSS, and support third-party SDKs.
Which scenario to choose
| Parameter | Redirect (Simple & Secure) | Embedded Form (Seamless UX) |
| User Flow | Buyer is redirected to a hosted payment page | Payment form appears directly on the store’s checkout page |
| Setup complexity | Minimal — plugin or hosted page | Higher — requires SDKs and front-end integration |
| Security & PCI DSS | Handled by the gateway provider | Shared between provider and merchant |
| UX & Conversion | May slightly drop if user doesn’t return after redirection | Higher conversion thanks to smoother checkout |
| Maintenance | Centralized — updates apply to all merchants automatically | Requires ongoing testing for compatibility |
| Apple Pay / Google Pay integration | Managed on the hosted page | Integrated into the checkout; requires token handling |
| Best for | Fast MVPs, small & medium merchants | Mature gateways, enterprise-level merchants |
| Main advantage | Easier to develop and maintain | Best customer experience and brand consistency |
| Main downside | Off-site experience | More complex compliance and development |
If you’re just launching your gateway and aiming to onboard stores at scale, redirect is the better choice. It’s faster to develop, safer for merchants, easier to maintain, and compatible with most CMSs.
Move toward an embedded form when:
- you’re working with larger merchants who care deeply about UX;
- you have the resources and expertise to meet security requirements;
- you want to offer a fully customized checkout experience with Apple Pay / Google Pay directly on the store’s site.
Choosing a platform for MVP
When you’re just starting out, speed matters. That’s why we almost always recommend launching on a single platform first — it helps you test your API and business assumptions faster, onboard your first stores, and gather real feedback.
WooCommerce is a great starting point. It’s one of the most popular eCommerce CMSs with open-source code, flexible architecture, and a large community. If your API is ready, you can release a WooCommerce plugin and get merchants using it in just a few weeks.
Other platforms are well-known too, but they come with additional complexity:
- Shopify and Wix are closed ecosystems. Their APIs are restricted, and any integration changes must go through the platform itself — not ideal when you want to move fast and test things freely.
- Magento, on the other hand, is powerful and flexible, but heavy to maintain. It requires a separate stack, a specialized team, and long-term support. It’s a good fit for later stages, once your product is stable and you’re ready to serve enterprise clients.
It’s better to launch on one CMS, fine-tune your flow, and scale from there — adapting your custom payment gateway to other platforms step by step. This reduces the load on your team and gets you results faster.
Don’t overlook security and compliance
A payment gateway handles sensitive data — so security must be built into its architecture from the very beginning.
There are a few core practices every gateway should follow:
- Encrypting all data in transit and at rest
- Validating incoming parameters
- Protecting against duplicate or fraudulent requests
- Using tokenized storage instead of card numbers
If you’re building an embedded form, it’s especially important that your payment fields don’t collect data directly. Instead, they should use secure browser-based tools to interact with your backend.
Beyond best practices, there are compliance standards to meet. If your system touches cardholder data, PCI DSS is non-negotiable. And depending on your region, you may also face local financial regulations — especially if you operate in tightly controlled markets.
The type of payment gateway integration you choose also affects who’s responsible for what:
- With a redirect flow, most of the compliance burden falls on you — since the entire payment happens on your hosted page.
- With an embedded form, some responsibilities shift to the merchant. That’s why it’s critical to define who handles what — from tokenization to rendering payment methods and transmitting data to your API.
We help you design gateways that follow the right standards and reduce compliance risks — both for your team and your merchants.
Conclusion
A payment gateway affects everything — from how fast merchants can get started to how stable and scalable your fintech product becomes. It’s a strategic component that:
- helps you control service quality,
- reduces the load on your support team,
- simplifies scaling across markets and platforms,
- builds trust with merchants and partners.
To make sure your gateway truly supports your growth, you need to:
- design a robust API architecture,
- choose the right integration format (redirect or embedded),
- meet security standards (including PCI DSS),
- account for platform-specific and regional requirements.
Our team can step in at any stage: we’ll help you assess risks, design the architecture, build the plugin, and adapt your gateway for the most popular CMSs.
👉 Learn more about payment gateway development
