Payment Gateway Software Development: Payment Gateway Development Services for Payment Companies and Platforms

Updated October 2026 · Written and maintained by the Progression Agency strategy team

Payment gateway software development is the design and build of the system that takes a payment request from a checkout, app or terminal, protects the card or bank data, sends it to a processor or acquirer for authorization, and returns a clear answer to the merchant, along with the dashboards, webhooks, refunds and reconciliation behind it. Payment gateway development is rarely about replacing the card networks; most teams build a gateway layer on top of one or more processors to own the checkout, the routing and the merchant experience, while the acquirer and its partners hold sponsorship and registrations. This page covers what a gateway does, gateway versus processor, whether to build your own, how to build a payment gateway step by step, architecture and features, PCI DSS scope, 3-D Secure, payfac and marketplace models, and what the work costs. We build payment gateway software for payment companies, fintechs and platforms, starting with a free proposal and a written scope.

What is payment gateway software development?

Payment gateway software development is the engineering of the service that sits between a place where someone pays and the companies that move the money. A checkout page, a mobile app or a card terminal hands over a payment request; the gateway protects the card or bank details, sends the request on to a processor or acquirer, and tells the merchant what happened. The same software also carries the less visible parts: dashboards, refunds, dispute tools, webhooks, settlement files and the records that let a finance team prove every cent. So when someone asks whether a payment gateway is software, the answer is yes, with one caveat: the gateway is only one link in a chain of regulated parties, and the software has to be built to fit them.

Our fintech software development page covers the wider field of financial products. This page is about the gateway layer itself and about the companies that need to own one.

Who builds a gateway

Five kinds of organization commission this work, and each wants a different slice of it:

• Payment service providers and ISOs that sell processing to merchants and want their own API, dashboard and pricing logic.
• Payment facilitators that onboard many small sellers under one acquiring relationship.
• Banks and fintechs that need a gateway layer for a card or account product.
• SaaS and marketplace platforms that take payments on behalf of their customers and want to control checkout, routing and payouts.
• High-volume merchants that route traffic across several processors to protect uptime and manage cost.

What we build and what your acquirer holds

We build the software: the API and SDKs, hosted payment fields, processor connections, onboarding workflows, dashboards, webhooks, reconciliation tools and the security engineering around them. Your acquirer, sponsor bank and processors hold the things software cannot supply: the merchant accounts, the sponsorship, the network registrations and the contracts that let money move. Progression holds none of those on your behalf, and a proposal says plainly which of them your program needs from partners before launch.

Payment gateway development: gateway, processor, acquirer and network

Payment gateway development starts with a clear map of who does what in a card payment, because the map decides what is built and what is bought. The parties are few, but the words for them get mixed up, and an unclear scope is where most gateway budgets go wrong. If you are also deciding how invoices and subscriptions will flow into the gateway, our billing software development page covers that side.

Payment gateway vs payment processor

The gateway is the part that faces the merchant. It accepts the request, validates it, protects the card details and passes a clean message along. The processor is the connection behind it: it carries the message to the acquirer and the card network and brings back the issuer’s decision. One company can offer both under one name, and one gateway can sit in front of several processors, which is why contracts and architecture diagrams need to say which function is meant. The Payment Card Industry Security Standards Council lists merchants, processors, acquirers, issuers and service providers as the entities involved in payment card processing, which is a useful reminder that the gateway fits one of those roles for each client.

Payment gateway vs payment network and payment platform

The card networks sit further along the chain, between the acquirer’s side and the issuing bank. A payment platform is a looser term: it usually means a bundle of gateway, processing, onboarding and reporting sold as one product. Neither word tells you what software exists, so a requirements document should list the functions rather than the label.

Where tokenization and the vault sit

Tokenization replaces a card number with a stand-in value that is useless outside your system. The vault is the protected store that maps tokens back to card details, and in many designs it belongs to a processor or a specialist vendor rather than to the gateway. Where the vault sits is one of the earliest decisions on the project, because it sets how many of your systems ever see a card number.

Payment gateway development services

Payment gateway development services cover the whole of the software around a payment, not only the API call. Payment processing development of this kind usually breaks into the seven pieces below, and a proposal should say which are new builds, which extend something you have and which connect to a vendor.

Gateway API and SDKs

The API is the gateway’s public promise. A good one has predictable resources for payments, captures, voids and refunds, clear error codes, versioning that does not break merchants, and a sandbox that behaves like production. SDKs and sample code for the languages your merchants use shorten their time to a first test payment, and a changelog tells them what moved.

Hosted payment pages and fields

Hosted fields and hosted pages let a merchant show a card form that is served from your domain or your processor’s, so the merchant’s own pages and servers never receive a card number. They are the single most effective way to shrink the amount of software that has to be protected. Styling options, mobile behavior and accessibility need as much care as the security does.

Processor and acquirer connections

Each connection is its own small project: authentication, message formats, error mapping, test cards and a certification step run by the processor. Connecting a second processor is cheaper than the first only if the first was built behind an internal interface, which is why the design work comes before the integration work.

Merchant onboarding and KYB workflows

If your gateway serves other businesses, it needs a way to collect their details, run the checks your acquirer requires and decide who is approved. We build the workflow, the document handling and the review queue around the identity and business verification vendor you choose; we do not write screening rules of our own.

Dashboards, refunds, disputes and reporting

Merchants judge a gateway by its dashboard. They want to search a payment, refund it, see the dispute that arrived overnight and export a statement. Back-office roles, audit trails and permission levels belong in the same build, because support staff will use these screens all day.

Webhooks, idempotency and retries

Networks fail in small ways all the time. An idempotency key lets a client resend a request without charging twice, and webhooks tell a merchant’s system what happened when its connection dropped. Both need to be designed as features, with retry schedules, signing and a way to replay events from the dashboard.

Reconciliation and settlement files

Money has to match. Processors send settlement and fee files on their own schedules and in their own formats, and the gateway’s records must be compared with them every day. The software parses the files, matches each line to a payment and shows the breaks a person has to clear.

Custom payment gateway or a processor’s API?

Can I create my own payment gateway? Yes, in the sense that matters for most teams: a gateway layer of your own, sitting on one or more processors. The decision is whether that layer earns its cost. For many companies a processor’s own API and hosted pages are enough, and a custom payment gateway would only add work. For others it is the product.

When a processor’s API is enough

If you sell your own goods or services through one processor, if your checkout needs are ordinary and if switching processors is not a plan, the processor’s API and hosted checkout will do the job. The money you would spend on a gateway is better spent on your product. Our ecommerce app development page covers building checkouts on top of those APIs.

When a gateway layer of your own pays off

A gateway layer pays off when you have several processors and want to route between them, when you resell payments to your own merchants under your brand, when you run a payment facilitator model, or when you need controls over retries, fallbacks and reporting that no single processor provides. Those are product reasons, and they should be written down before work starts.

White label payment gateway vs custom payment gateway

A white label payment gateway is a product from an existing provider that you rebrand and resell, usually with limits on what you can change. A custom build gives you the roadmap and the code, along with the cost and the responsibility of running it. Neither is better in general. The honest comparison is between what a white label product lets you do, what you need to do, and the gap in between.

How to build a payment gateway

How to build a payment gateway comes down to six steps taken in order. The same sequence answers how to create a payment gateway for a bank, a platform or a payments startup, and how to build a payment gateway website that merchants can sign up on. Build a payment gateway in this order, and the hardest questions get answered while they are still cheap to change.

Step 1: decide the model and the partners

Decide whether you are a payment service provider, an ISO, a payment facilitator or a platform that uses a gateway for its own sellers. Choose the acquirer and the processors that will support that model, and talk to counsel about licensing for the markets you will serve. The software does not change these decisions; it follows them.

Step 2: map PCI DSS scope before writing code

Draw where card data will enter, travel and rest. Decide whether card entry will be hosted, where the vault will sit and which systems will only ever see tokens. Review the diagram with the assessor or acquirer who will judge it, because a scope decision made after the code exists is expensive to reverse.

Step 3: design the API, data model and ledger of events

Write the API contract, the payment state machine and the event log before the screens. A payment is a series of states, such as authorized, captured, voided or refunded, and the system should record every change as an event that can be replayed. This is the part that makes reconciliation and dispute handling possible later.

Step 4: integrate processors, 3-D Secure and tokenization

Build the processor connections behind one internal interface, add 3-D Secure where card-not-present payments need it, and wire in the tokenization service. Test each connection in the processor’s sandbox, and test failure cases such as timeouts and duplicate requests as hard as the success path.

Step 5: build onboarding, dashboards and reconciliation

Merchants need to sign up, be reviewed, see their payments and get paid. Your finance team needs to see that every payment matches a settlement line. These screens and jobs take longer than the payment call, and they are what merchants and auditors actually use.

Step 6: test, certify with each processor and launch

Each processor runs its own certification program, with its own test scripts and sign-off. Plan time for that and for load, security and recovery testing. Launch to a small set of merchants first, with low limits and close monitoring, then widen. Processor certification is the processor’s program, not a PCI credential and not something Progression grants.

How hard is it to build a payment gateway?

The code is the smaller part. The hard parts are the partners, the security scope and the testing: a gateway needs an acquirer relationship, a clear PCI DSS scope, certification with each processor and a way to run reliably every hour of every day. A team that treats it as a normal web project underestimates all three. A team that starts from the partner model and the scope diagram usually finds it a hard but ordinary engineering job.

How long does it take to build a payment gateway?

No honest answer exists before the model, the partners and the scope are known. A thin layer over one processor, a multi-processor routing platform and a payment facilitator program are very different amounts of work, and partner approvals and processor certification often set the calendar more than coding does. We agree phases and dates in the written scope, and we do not promise a fixed timeline in advance.

How to build a payment gateway from scratch, and why few teams should

To build a payment gateway from scratch would mean owning every function, including a direct connection to the networks and your own card vault. Few teams should, because the functions that cost the most to build and protect are the ones partners already provide. The usual pattern is to build the layer that makes you different, such as the API, routing, onboarding and reporting, and to buy or connect the rest.

Payment gateway requirements

Payment gateway requirements fall into three kinds, and a specification that covers only the first kind is the usual cause of late surprises. The checklist below names the items; it does not say which must be met, because that depends on your model and your acquirer.

Functional requirements

These are the things merchants see: create a payment, authorize and capture it, void it, refund it fully or partly, store a payment method for later, receive an event when something changes, and download a statement. Add the admin side: roles, merchant status changes, manual review and a search that finds a payment from any identifier a customer or merchant might quote.

Security and compliance requirements

List what must be protected and how: card data, authentication, access to the dashboard, keys and secrets, logging and the evidence an assessor will ask for. Record which controls come from the processor or vault vendor, which are built by your team and which are procedures rather than software.

Operational requirements: uptime, monitoring, support

A payment system is judged when it fails. Write down the availability you need, how failover works, what is monitored, who is paged and how a merchant reaches a person. These requirements shape the infrastructure and the on-call plan as much as the code.

Payment gateway features merchants expect

Payment gateway features are what separate a product merchants choose from one they tolerate. The list below covers the features a merchant checks for first; the order of build follows your merchants and your model.

Payment methods: cards, ACH, wallets and real-time payments

Cards come first for most gateways, followed by bank debits, digital wallets and, depending on the processors, real-time bank payments. Each method has its own flow, reversal rules and settlement timing, so the internal payment model has to treat them as variations of one thing rather than as separate code. Wallet products as such are covered on a separate page.

Recurring payments and stored credentials

Subscriptions and saved payment methods need a vault token, a schedule, a retry plan for failed charges and a way for customers to update a card. The scheduling and invoicing logic usually belongs in a billing system; our billing software development page covers it.

Fraud tools and risk rules

Risk checks can come from the processor, a specialist vendor or your own rules. A gateway should make them configurable: rules a risk analyst can change, a review queue, and a clear record of why a payment was declined. No fraud statistics are quoted here, because the right comparison is between designs, not headlines.

Multi-currency and payouts

Multi-currency means pricing, conversion, settlement in the right currency and reporting that stays consistent. Payouts mean sending money to merchants or sub-merchants on a schedule, with a ledger that shows what is owed, what has been paid and what is held.

PCI DSS and payment gateway software

PCI DSS is the standard that most payment gateway software is designed around. The PCI Security Standards Council describes it as a baseline of technical and operational requirements designed to protect payment account data. This section restates what the Council publishes and what that means for design. It is not an assessment, and it does not say whether any particular company is in scope; your acquirer and your qualified assessor decide that. Read the Council’s PCI DSS page and its Document Library for the documents themselves.

What PCI DSS covers

The Council says PCI DSS applies to entities that store, process or transmit cardholder data or sensitive authentication data, or that could affect the security of the cardholder data environment, and that this includes merchants, processors, acquirers, issuers and service providers. A gateway fits that description in almost every design. When this page was prepared in October 2026, the Document Library featured PCI DSS v4.0.1 together with a summary of changes from v4.0 to v4.0.1; check the library for the version your assessor expects.

Shrinking scope with tokenization and hosted fields

The surest way to reduce what has to be protected is to reduce what is held. Hosted card entry keeps numbers off the merchant’s pages, a vault keeps them in one place, and tokens let every other system work without them. The diagram below shows the idea as a design pattern.

Fewer systems touching card numbers also means a shorter conversation with the assessor, a smaller set of logs and secrets to guard, and a simpler answer when a merchant sends a security questionnaire.

Other PCI SSC standards a gateway may touch

PCI DSS is one of several standards on the Council’s standards page. Depending on the design, a gateway project may meet some of the others:

• The PCI 3DS Core standard, which sets security requirements for environments where specific 3-D Secure functions are performed.
• The Point-to-Point Encryption standard, which covers encryption of payment data from the merchant’s payment device to the solution provider’s environment.
• The Token Service Provider standard, for providers that generate and issue EMV payment tokens.
• The Secure Software and Secure Software Lifecycle standards, which set security requirements for software vendors and developers; they superseded PA-DSS, which the Council lists as retired as of October 28, 2022.
• The PIN Security standard and the standards for Mobile Payments on COTS, which matter mainly when terminals or phones accept cards.

The Council’s Software Security Framework page explains how its software standards fit together. We name these standards so you can ask your acquirer which apply; Progression holds no listing under any of them.

Do you need PCI DSS validation to run a gateway?

The Council’s standard says whom it is intended for; what a given company must validate, and in what form, is decided with its acquirer and its qualified security assessor. Ask both early, in writing, and design for their answer. We design the software to reduce scope and to support your assessment; we do not claim PCI certification for ourselves.

Card-present payments

A gateway that also takes card-present payments adds terminals, encryption between the reader and the processor, and a different set of standards. Our POS software development page covers that side in detail.

3-D Secure, tokens and authentication

3-D Secure is the authentication step for card-not-present payments, and a gateway has to support it cleanly. EMVCo describes EMV 3-D Secure as a way for card issuers and merchants to authenticate the consumer and guard against card-not-present fraud, with data about the transaction, the payment method and the device exchanged between the merchant and the issuer. EMVCo maintains the specifications and works with the PCI Security Standards Council on the security evaluation of 3-D Secure solutions. See the EMVCo overview for the current specifications.

What does 3-D Secure do for a gateway?

It adds a conversation with the issuer to the payment flow. The gateway collects the data the issuer asks for, handles the challenge screen when one is needed, and carries the outcome into the authorization request. Build it behind a feature switch so each merchant can use it where it makes sense, and log every step so declines can be explained to merchants and to support.

Payment tokens and stored credentials

There are two kinds of token in a gateway design. Your own tokens stand in for card numbers in your systems. EMV payment tokens are generated and issued by token service providers, and the Council publishes a standard for those providers. Which of them you can use depends on your processors and acquirer.

Payment facilitators, marketplaces and split payments

Platforms that collect money for other businesses need more than a checkout. They need to sign up sellers, hold or route funds, split one payment into several and pay everyone on schedule. Our marketplace development page covers the platform that sits above those flows; this section covers the payment software underneath.

Sub-merchant onboarding as a payfac

In a payment facilitator program, a platform onboards sellers as sub-merchants under its own acquiring relationship. The software has to collect business details, route them through the verification vendor, record decisions, set limits and let a person review exceptions. The registration and sponsor duties of a payfac come from the acquirer and the card network programs, so the build follows what they require.

Split payments and payouts

A split payment divides one customer charge among the platform and one or more sellers; a payout moves each party’s share to a bank account. Both need a ledger that shows every amount, holds, reversals and fees. Federal rules on money transmission can matter here. The federal definition in 31 CFR 1010.100 says whether a person is a money transmitter is a matter of facts and circumstances and excludes a person that only acts as a payment processor, under an agreement with the creditor or seller, to facilitate the purchase of a good or service through a clearance and settlement system. Whether a given design qualifies is a question for your counsel.

Payment gateway integration for checkouts and platforms

Payment gateway integration is the other half of the work: getting your gateway into the places merchants sell. That means well-documented APIs, hosted checkout, mobile SDKs and plugins. Merchants on common store platforms expect a plugin, and our WooCommerce development team and Shopify agency team build plugins and apps for those stores. For merchants with custom storefronts, our ecommerce app development team can build the checkout against your API, and our API development page covers the interface design in more depth.

Wallets, P2P and payment apps

Wallet and peer-to-peer apps usually connect to a gateway or a processor rather than becoming one. A wallet that holds a balance has different rules and a different ledger from a gateway that passes card payments along, and the two projects are scoped separately. We cover wallet and P2P app development on its own page, and a platform that needs both usually builds the wallet on top of a gateway layer like the one described here.

Security engineering for a payment gateway

Security is part of how the gateway is built, not a layer added at the end. The notes below describe the engineering practices; they are not a promise of any certification.

Encryption, key management and secrets

Encrypt data in transit and at rest, keep keys in a managed service with limited access, rotate secrets on a schedule, and separate the people who can deploy from the people who can read production data. Decisions about hardware security modules and key custody belong to the client and the assessor; we build the software to use whichever service they choose.

Application security testing

The OWASP Application Security Verification Standard is a framework of security requirements for designing, developing and testing modern web applications and web services. Version 5.0.0 was published on May 30, 2025. It gives a gateway team a concrete list to test against, from authentication to API design. Read it on the OWASP project page.

Logging, monitoring and incident response

Log every payment state change and every administrative action without logging card numbers or secrets. Alert on unusual patterns, and write the incident response steps down before they are needed: who is called, what is shut off and how merchants are told.

Gateway economics: how payment gateways make money

How do payment gateways make money? Through the fees written into their merchant agreements, and the software has to price, meter and report on whatever structure the contract sets. Fee structures a gateway’s billing may need to handle include a fixed fee on each transaction, a percentage of the amount, a monthly or annual platform fee, setup fees and extra charges for services such as chargeback handling. We publish no rates here, because they depend on the acquirer, the card mix and the contract.

The practical build question is flexibility. Pricing that is stored as data, with effective dates, merchant-level overrides and clear invoices, lets the business change terms without a code release.

Payment gateway development cost

Payment gateway development cost depends on the model, the number of processors and payment methods, the PCI scope and how much onboarding and reporting you need. How much does it cost to build a payment gateway? Nobody can say without a scope, and the table below shows why: the range for custom software in general is wide. Payment gateway software development sits toward the upper part of it because of security work, scope decisions and processor testing. Our fintech software development page covers financial products more broadly.

Our prices

Gateway builds are quoted after a written scope. We publish no Progression price or hourly rate for them, and a free proposal comes first.

Published US price bands

Published figures describe what software developers charge in general, not a Progression quote and not a price for a gateway in particular:

What moves the cost: processors, payment methods, PCI scope and onboarding

Four things move a gateway budget more than anything else. Each additional processor adds an integration and a certification. Each additional payment method adds a flow, a reversal path and a settlement format. A wider PCI scope adds controls, evidence and testing. And a merchant-facing program adds onboarding, review queues, dashboards and support tools. A written scope that names all four shrinks the range.

• Processors: one integration and one certification each.
• Payment methods: one flow, reversal path and settlement format each.
• PCI scope: controls, evidence and testing grow with the number of systems that touch card data.
• Merchant tools: onboarding, review queues, dashboards and support screens.

How to choose a payment gateway development company

Choose a payment gateway development company on how it handles the hard parts, not on how many logos it shows. Payment gateway development company or payment gateway software development company, the questions are the same, and any firm, including us, should answer them in writing.

Questions to ask before you sign

Six questions separate firms that have thought about payments from those that have not:

Red flags

A few answers should end the conversation:

• A promise that PCI scope will be zero, or a claim of PCI certification that the firm cannot show.
• A claim to be a payment facilitator, bank partner or network member without a name and a contract to point to.
• No plan for what happens when a processor times out or a request is sent twice.
• A refusal to say who owns the code, the keys and the cloud accounts.
• A fixed price quoted before anyone has asked who your merchants are.

More pages on the services around a gateway build:

• Fintech software development
• Billing software development
• POS software development
• Marketplace development
• API development
• Lending software development
• Software development company

Frequently asked questions