How to Build a Payment Processing App in 2026: Gateway, Embedded or PayFac
A payment form takes a day to add. A payment processing app takes much longer, because the real work starts after the customer taps Pay: settlement, fees, payouts, refunds, disputes and reconciliation, for every merchant you serve. The good news is that you rarely need to become a processor to earn from payments. Here is how to pick the right model for your business and build a payment app that holds up when real money and real merchants arrive.
Adding payments to your product?Tell us who your merchants are and how money should flow between them, you and their customers. We’ll recommend a build model and scope the payment stack.
Scope my payment stackFirst, name the payment app you are building
People search for "how to build a payment app" with four very different products in mind. Each has a different buyer, risk and scope:
- A merchant app. Your own store, booking or service app takes payments for itself. You are the merchant. This is mostly a gateway integration.
- A SaaS platform adding payments. Your software serves gyms, clinics, contractors or restaurants, and you want them to take payments inside it. Payments become a revenue line for you.
- An ISO or agent. You sell merchant accounts for an acquirer and want branded onboarding, dashboards and reporting for your merchants.
- A future payment facilitator. You want to onboard merchants under your own master account, move their money and own the margin.
If you are building a consumer app that moves money between people, that is a different product: see how to build a P2P payment app.
Start with three decisions
For the last three readers, three questions set the scope and the risk:
- Who is the merchant of record? Each of your customers, or you. This decides whose name is on the card statement and who answers disputes.
- Who carries the loss when a merchant disappears? The provider, or you. Liability for chargebacks and fraud is what separates the models.
- Whose servers touch card data? Only the provider's, or yours too. This decides your PCI DSS scope.
- Examples: a merchant app, an online store, a subscription product, an ISO portal on top of an acquirer's APIs.
- You rent: the gateway and processor, hosted fields, the token vault, fraud tools, dispute handling.
- You build: checkout, the order and payment states, webhook handling, refunds, reporting.
- Watch out: relying on the browser redirect instead of webhooks. Customers close the tab after paying, and orders go missing.
- Examples: vertical SaaS taking payments for its customers, marketplaces paying out sellers, booking platforms.
- You rent: a PayFac-as-a-service provider (such as Stripe Connect, Adyen for Platforms, Finix or Payrix) that underwrites merchants, holds the licenses and moves the money.
- You build: merchant onboarding inside your product, fee and split logic, a ledger of merchant balances, payouts views, dispute handling, merchant dashboards.
- Watch out: who carries losses and who files tax forms differs by provider and account type. Read the platform agreement before you design onboarding.
- Examples: platforms with large card volume where the revenue share from embedded payments has become a major cost.
- You rent: less: a sponsor bank and acquirer register you with the card networks, and a processor handles authorization and settlement.
- You build: sub-merchant underwriting and monitoring, funding and payouts, reserves, risk tools, a service provider PCI DSS program.
- Watch out: you are liable for every sub-merchant's chargebacks and fraud. A PayFac without strong underwriting can lose more on one bad merchant than it earns in a year.
Many platforms start embedded and revisit the PayFac question once volume is large. Switching later is easier if you own your merchant data and can export stored cards through a compliant migration, so put both in the provider contract.
How to build a payment processing app, step by step
Nine steps for a platform that processes payments for its customers. A merchant app can skip steps 3 and 6.
- Draw the money flow on one pageWho pays, who gets paid, who takes a fee, when refunds happen and who funds them. Every actor, every state, every arrow. This page makes vendor quotes comparable and catches the expensive surprises before code.
- Choose the model and provider, start underwritingCompare providers on pricing (flat, or interchange-plus once volume is large), revenue share, supported payment methods, payout speed, onboarding APIs and who carries losses. Account approval and platform review take time, so start in week one.
- Design merchant onboarding (KYB)Business details, beneficial owners, bank account verification and identity checks, with a path for merchants who fail automated checks. Use the provider's hosted onboarding first if you can; build your own screens once you know where merchants drop off.
- Keep card data out of your serversUse hosted fields or the provider's mobile SDK, so card numbers go straight to the provider and you store only tokens. Network tokens and card updater services keep saved cards working when cards are reissued.
- Build the payment API and webhook inboxEvery request carries an idempotency key. Every provider event lands in an inbox, gets deduplicated, then updates your payment states. Model authorized, captured, partially refunded, refunded, failed and disputed from the start.
- Add fees, splits and payouts on a ledgerRecord each payment, fee, refund and payout as ledger entries per merchant. Support payout schedules, reserves for risky merchants, and negative balances when a refund or dispute arrives after the payout.
- Reconcile every dayMatch your records to the provider's settlement and payout reports, and payouts to bank deposits. Alert on any difference. Finance teams and merchants will ask why a deposit is $12.40 short; reconciliation is how you answer.
- Build refunds and disputes as workflowsRefunds with permissions and limits. Disputes with a timeline, evidence upload, response deadlines and automatic merchant debits under your terms. Card networks run monitoring programs for accounts with high dispute or fraud rates, so track the ratio per merchant.
- Ship merchant dashboards, then pilotTransactions, payouts, fees, disputes and exports in one place. Launch with a handful of friendly merchants and low volume, watch reconciliation and support tickets, then open onboarding to everyone.
What you build and what you rent
Even a platform that earns from payments rents most of the payment network. What it builds is the layer its merchants see and the books that keep everyone paid correctly. A typical split for embedded payments:
| Layer | Usually rented | Usually built |
|---|---|---|
| Card acceptance | Gateway, processor, hosted fields, mobile SDKs, Tap to Pay | Checkout UX, payment method display, receipts |
| Card data | Token vault, network tokens, card updater | Saved payment methods tied to your customers |
| Merchant onboarding | KYB checks, underwriting, sanctions screening by the provider | Onboarding flow in your product, status tracking, re-verification prompts |
| Money movement | Settlement, payouts to bank accounts, instant payouts | Fee and split logic, payout schedules, reserves, merchant ledger |
| Risk and disputes | Fraud scoring, network dispute systems | Rules for your vertical, dispute workflow, merchant risk views |
| Reporting | Provider settlement and payout reports | Reconciliation, merchant dashboards, finance exports |
On the SaaS side, the line between rented and built moves over time. Start with as much hosted as possible, and replace pieces with your own UI where merchants ask for it.
Technical rules for payment processing
The bugs that cost platforms the most are rarely in the checkout. They are in what happens after it. These rules prevent most of them.
- Stay out of card data. Hosted fields or SDKs keep raw card numbers off your servers and your PCI DSS scope small. Since PCI DSS v4.0.1 took full effect on March 31, 2025, even pages with hosted fields need protection against malicious scripts.
- Webhooks are the source of truth. The browser redirect is a hint. Payment states change from provider events, verified by signature, stored first, deduplicated, then processed.
- Idempotency on every write. Captures, refunds and payouts all carry unique keys. A retried request must never charge, refund or pay twice.
- Money as integers, in a ledger. Store amounts in minor units with the currency. Merchant balances come from entries for payments, fees, refunds, disputes and payouts, never from a column someone updates.
- Plan for negative balances. Refunds and disputes arrive after payouts. Decide in the merchant agreement how you recover them: from future payouts, a reserve or a bank debit.
- Reconcile three ways. Your ledger against the provider's settlement report, and provider payouts against bank deposits, every day, with alerts on gaps.
General information, not legal advice
Becoming a payment facilitator involves card network registration through a sponsor bank, merchant underwriting duties, PCI DSS validation as a service provider, and possibly money transmission and tax reporting questions such as IRS Form 1099-K. Embedded payment providers take on much of this, in ways that differ by contract. Confirm your obligations with payments counsel and your provider.
What goes into the first version
A first payment release for a platform covers one payment method, one payout path and every unhappy path. A typical split:
| At launch | Can wait |
|---|---|
| Card payments with hosted fields, Apple Pay and Google Pay | ACH debits, buy now pay later, local payment methods |
| Provider-hosted merchant onboarding with status tracking | Fully custom onboarding screens |
| Platform fee logic and standard payouts | Instant payouts, multi-party splits |
| Refunds, dispute workflow and evidence upload | Automated dispute responses |
| Webhook inbox, merchant ledger, daily reconciliation | A second provider and payment routing |
| Merchant dashboard: transactions, payouts, fees, CSV export | Card-present terminals and Tap to Pay |
| Saved cards with network tokens | Level 2 and Level 3 data for B2B card rates |
A second gateway roughly doubles the payment code you maintain. It usually makes sense only at a few million dollars a year in card volume, or when an outage at one provider would be very expensive.
Built by Gilzor
Results we’ve shipped
70+products launched
98%delivered on time
85%clients come back
Aviation33%faster baggage weigh-inWeb and Mobile application for Airlines→Healthcare+30%lab test ordersMedical Lab Web and Native Mobile Applications→Retail · Startup700+stores aggregatedMobile application for Grocery shops→
Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.
Timeline and budget at a glance
$10–35kEmbedded checkout in your own web or mobile UI, 4–8 weeks
$35–150kSubscriptions, usage billing or marketplace payouts, 2–5 months
$150k+Multi-gateway routing or a direct processor connection
15–20%Of the build per year for maintenance and provider API changes
Fees usually outgrow the build: at $100,000 a month in card sales, standard 2.9% + 30¢ pricing costs about $40,000 a year. Becoming a PayFac adds registration, underwriting and compliance work on top of these figures. Our payment gateway integration cost guide has the full breakdown, PCI scope by integration style and a calculator.
Mistakes that cost the most later
- Becoming a PayFac too early. The margin looks attractive, but underwriting, loss liability and a service provider PCI program arrive on day one. Embedded payments first, PayFac once volume pays for the risk team.
- Not owning your merchant and card data. Without the right to migrate stored cards and merchant records, switching providers means asking every customer to re-enter a card.
- Paying out before you can claw back. Fast payouts with no reserve and no negative balance terms turn every late dispute into your loss.
- Treating refunds as a button. Partial refunds, refunds after payout, refunds on disputed payments: each needs a rule and a ledger entry.
- No reconciliation until finance complains. Small gaps compound. A daily automated match finds them while they are still easy to explain.
- Ignoring dispute ratios. One merchant with heavy disputes can put your whole platform account under network monitoring. Track ratios per merchant and act early.
Payment processing readiness checklist
Tick what is already true. It shows how ready your payment stack is for live merchants.
Payment processing readiness
FAQ
How do I build a payment processing app?
First decide which product you are building: a merchant app that takes payments for itself, a software platform that processes payments for its customers, or a payment facilitator. Then pick the build model: integrate a gateway, embed payments through a PayFac-as-a-service provider, or register as a PayFac with a sponsor bank. Keep card data out of your servers with hosted fields and tokens, build an idempotent payment API with a webhook inbox, add a ledger for fees and merchant balances, reconcile against settlement reports every day, and build refund, dispute and payout workflows before you onboard the first live merchants.
How do I build a payment app like Stripe or Square?
Stripe and Square are payment facilitators and processors at enormous scale, with years of risk, compliance and infrastructure behind them. Most companies that say they want to build one actually need embedded payments: their software onboards merchants and takes payments through a PayFac-as-a-service provider, and they earn a share of the revenue. Becoming a PayFac yourself means sponsor bank registration, merchant underwriting, liability for merchant losses and a larger PCI DSS program, so it is usually a later step once volume justifies it.
How long does it take to build a payment processing app?
A hosted checkout takes one to two weeks, and an embedded checkout in your own web or mobile UI four to eight weeks. Platform payments with merchant onboarding, split payments and payouts usually take two to five months, mostly because of edge cases and reconciliation. Becoming a PayFac takes considerably longer, because registration, underwriting tools and compliance work run alongside the build.
How much does it cost to build a payment processing app?
With a development vendor, an embedded checkout costs about $10,000–35,000, subscriptions or marketplace payouts $35,000–150,000, and multi-gateway routing or a direct processor connection starts around $150,000. Processing fees often matter more: at $100,000 a month in card sales, standard 2.9% + 30¢ pricing is about $40,000 a year. Our payment gateway integration cost guide breaks this down with a calculator.
What is the difference between a PayFac and an ISO?
An ISO (independent sales organization) resells an acquirer’s merchant accounts: it finds merchants, but each merchant gets its own account with the acquirer, and the ISO usually does not move the money. A payment facilitator onboards merchants as sub-merchants under its own master account, receives the funds, pays merchants out and is liable for their chargebacks and losses. That is why PayFacs can onboard merchants in minutes, and why they carry more risk and compliance work.
Do I need PCI DSS compliance for a payment app?
Yes, every business that accepts or processes cards has PCI DSS obligations, but your design decides how large they are. With hosted fields or a hosted payment page, a merchant can often use the short SAQ A. Handling raw card data moves you toward SAQ D and far more controls. A PayFac or any company that stores, processes or transmits card data for others is a service provider with stricter validation, and large service providers need an annual assessment by a Qualified Security Assessor. PCI DSS v4.0.1 has been fully in effect since March 31, 2025.
Where Gilzor fits
We build web platforms and mobile apps with the backend and integrations behind them, including fintech work such as KYC onboarding with providers such as Sumsub and transfer and withdrawal flows. On QA, only 5% of the tasks we send to testing come back to developers. For KickEX, our team refactored the architecture and rewrote unstable code. We work from Poland and Cyprus, with a few shared hours a day with the US East Coast.
Send us who your merchants are, how money should flow between them, you and their customers, and the provider you use or are considering. We'll recommend a build model and scope the payment stack for a first release. If your product is a bank account rather than a payment flow, see how to build a banking app.
No sales pitch
Get a straight answer for your project
Tell us what you’re building. We’ll reply with options, a rough cost and timeline. If we’re not the right fit, we’ll say so.
Something went wrong. Please try again, or email us at contacts@gilzor.com.
Written byAndrew Laminsky
CTO of Gilzor. Responsible for architecture and the engineering standards our teams work by.
LinkedIn →Gilzor · Web Development partner
Need a team for your web product?
95%referred by business partners
70+successful launches
85%repeat business
98%delivered on time
Services
Web DevelopmentCustom websites and web apps — front-end, back-end, launch and support.→UX/UI DesignIntuitive interfaces for web and mobile products.E-commerceOnline stores, marketplaces and their integrations.AI/ML SolutionsComputer vision, NLP, predictive analytics, automation.Quality AssuranceManual, automated and performance testing.Development SupportTeam extension, maintenance, bug fixing, scaling.Our Tech StackReact, Node.js, Python, AWS, Docker, Kubernetes.
By company type
Selected projects
The team behind them
Tell us what you’re buildingOptions, a rough cost and timeline for your project. No commitment.
