How to build an app like Stripe: marketplace payment infrastructure explained

When someone says "I want to build something like Stripe," they almost never mean they want to connect directly to Visa and Mastercard, manage card data on their own servers, and obtain a principal payment processor license. That path costs tens of millions of dollars and years of regulatory approval.

What they actually mean: they are building a marketplace, an on-demand platform, or a financial services product, and they need the same payment infrastructure capabilities Stripe has. Split payments when a buyer pays and a seller receives. Escrow that holds funds until a service is confirmed complete. Payout scheduling with KYC for sellers. Subscription billing with proration and dunning. A ledger that tracks exactly who owes what.

That build costs $80,000-$130,000 and takes 12-16 weeks. It runs on top of Stripe Connect or Adyen as the underlying card processor. Your platform provides the business logic. The processor provides the financial rails.

This guide covers what that business logic build actually involves, component by component.

What "an app like Stripe" actually means to build

Stripe's real value is not the payment form. Any payment processor can give you a checkout form. Stripe's value is the infrastructure layer underneath: ACH transfers, card processing, digital wallets, subscription management, marketplace split payments, payouts to sellers, tax calculation, fraud detection, and banking-as-a-service.

Most businesses building "a payment platform" need a subset of those capabilities applied to a specific context.

A freelance marketplace needs split payments: buyer pays $1,000, seller gets $850, platform keeps $150. It also needs escrow: hold the $1,000 until the buyer approves the delivered work, then release to the seller.

An on-demand service app needs payouts: after the service provider completes a job, calculate their earnings, deduct the platform fee, and initiate a bank transfer on a weekly schedule.

A SaaS company with usage-based billing needs subscription infrastructure: charge a base monthly fee plus overage for API calls above the included tier, with proration when a customer upgrades mid-cycle.

A financial services company building a white-label product for small businesses needs the whole stack: merchant onboarding with KYC, a ledger per merchant account, and configurable payout rules.

Each of these requires a different slice of payment infrastructure. None of them requires rebuilding the card network layer.

Core components to build

Payment intent flow

The payment flow starts when a customer initiates a purchase. The funds do not go directly to the seller. They go into your platform account first.

The payment intent captures the customer's card via Stripe.js hosted fields (more on why this matters in the PCI section), creates a charge against the card, and holds the funds in your platform account. The seller receives nothing yet. The ledger records the incoming payment.

This separation is what enables marketplace business models. The platform controls the money until fulfillment conditions are met.

The double-entry ledger

The ledger is the most critical component in any marketplace payment system. It is also the most commonly underbuilt.

A double-entry ledger records every financial event as two paired entries. A debit from one account and a credit to another. Every entry has a timestamp, a transaction ID, and a reference to the event that triggered it.

When a customer pays $100, the ledger records: customer payment received ($100 debit from customer), platform account credited ($100 credit). When the platform releases $80 to the seller and keeps $20, the ledger records: platform account debited ($80), seller account credited ($80). And separately: platform revenue recognized ($20).

The ledger must always balance. If it does not, there is a bug. In a system processing thousands of transactions, a bug in the ledger creates financial discrepancies that are extremely difficult to untangle after the fact.

This must be a relational database, specifically PostgreSQL, with proper transaction isolation. Every ledger write is wrapped in a database transaction. Either all entries for a split payment commit together or none do. There is no partial state.

Marketplace split

When a customer pays and the seller receives a portion, the split calculation happens in your application logic, not in Stripe. Your platform decides: the buyer paid $100, the seller gets 80%, the platform keeps 20%. That calculation produces the ledger entries described above and then triggers the actual money movement.

Stripe Connect handles the transfer from your platform account to the seller's connected account. But your code decides the amounts, timing, and conditions.

Payout scheduling

Sellers need to receive their money. Payout scheduling determines when and how.

Most platforms use a weekly or bi-weekly payout schedule. Your system runs a job at the scheduled time, queries the ledger for each seller's available balance (earned funds minus holds minus fees), and initiates an ACH transfer or instant payout via Stripe.

Available balance is not the same as total earned balance. A platform with 7-day escrow holds funds for 7 days before they become available for payout. A platform with a fraud reserve holds a percentage of earnings for 30 days. The payout scheduler must apply these rules correctly before releasing funds.

Seller bank accounts are verified via Plaid or Stripe Identity before the first payout. This prevents fraud and is required for 1099-K reporting when a seller earns more than $600 in a calendar year.

Escrow logic

Escrow holds funds between the buyer's payment and the seller's payout. On a freelance marketplace, funds are held until the buyer approves the delivered work. On an on-demand service app, funds are held until the service is marked complete. On a real estate platform, earnest money is held until closing conditions are met.

The escrow logic manages the hold state. When the release condition is met (buyer approves, service marked complete, closing confirmed), the funds move from hold to available in the ledger and the payout scheduler picks them up on the next run.

When the release condition is not met (buyer disputes, service canceled), the funds are refunded to the buyer and the ledger reversal is recorded.

Refund handling

Refunds are more complex than charges. A charge goes from the buyer to your platform account. A refund reverses that charge. But by the time the refund is requested, the funds may have already moved toward the seller's account.

The refund flow must: refund the buyer's card via Stripe, debit the seller's available balance in the ledger, and record both reversals. If the seller's available balance is insufficient (they already withdrew the funds), the platform may need to absorb the refund and recover from the seller separately.

This edge case needs explicit handling in your refund logic before you go live. It surfaces in production within weeks of launch.

Subscription billing

Recurring charges add complexity around proration, dunning, and upgrade or downgrade handling.

If a customer upgrades from a $50/month plan to a $100/month plan on day 15 of their billing cycle, they owe a prorated $25 for the remaining half-month on the new plan. The billing system must calculate this, charge it immediately, and set the next billing date correctly.

Dunning handles failed payments. When a card is declined, the system retries on a schedule (day 1, day 3, day 7), sends email notifications to the customer, and suspends the account after the final retry fails.

Stripe Billing handles dunning, proration, and upgrade logic well for standard SaaS subscriptions. If your billing model is straightforward, use Stripe Billing directly rather than building subscription logic from scratch.

KYC for sellers

Before a seller can receive payouts, they need to be verified. This covers identity verification (name, date of birth, address) and tax ID collection for 1099-K reporting.

Stripe Connect handles KYC for Express and Custom accounts using Stripe Identity. Plaid handles bank account verification for ACH payouts. Your platform orchestrates the onboarding flow and stores verification status per seller.

The tech stack

Backend: Node.js. The payment layer is API-driven. Node.js handles webhook processing from Stripe (payment confirmations, payout status, dispute notifications) well and has good SDK support.

Database: PostgreSQL. The double-entry ledger is relational by nature. PostgreSQL's transaction isolation is essential for ensuring ledger writes are atomic. This is not a use case for MongoDB or DynamoDB.

Payment processor: Stripe Connect or Adyen. Stripe Connect is the default choice for most marketplace builds. The API is well-documented, the onboarding flow for sellers is built-in, and the webhook reliability is strong. Adyen is more appropriate for platforms processing $50M+ GMV or needing multi-region processing with direct acquiring relationships.

Bank account verification: Plaid. Instant bank account verification for ACH payout setup. Plaid's Link flow handles the user-facing verification in minutes.

Idempotency: Redis. Every charge attempt stores an idempotency key in Redis before the Stripe API call. More on why this matters in the next section.

Hosted payment fields: Stripe.js or Adyen hosted fields. The card number never touches your servers.

How long it takes and what it costs

The team is typically: one senior backend engineer with payments experience, one frontend engineer for seller onboarding and payment UI, one QA engineer focused on edge cases and refund scenarios, and a product manager coordinating with your compliance and legal team.

The hardest technical challenge

Idempotency in payment operations is the problem that causes the most production incidents.

Here is the failure mode. Your application sends a charge request to Stripe. The request times out after 30 seconds. You do not know if Stripe processed the charge or not before the timeout. If you retry the request and Stripe did process it, the customer is charged twice. If you do not retry and Stripe did not process it, the customer's order is stuck in a limbo state with no payment.

The solution is idempotency keys. Before your application sends any charge request, it generates a unique key for that specific charge attempt and stores it in Redis. The key maps to the charge parameters and a status field. When you call Stripe, you include the idempotency key in the request header. Stripe guarantees: for the same key, it will return the same result regardless of how many times you call it.

If your request times out, you retry with the same key. Stripe either returns the original result (charge succeeded) or the error (charge failed). You never create a duplicate charge.

This system must survive server restarts. The idempotency key store must be persistent, not in-memory. Redis with persistence enabled, or a database table, handles this correctly. An in-memory store loses all keys on restart and the protection disappears.

The same principle applies to payouts and ledger writes. Every operation that moves money needs an idempotency guarantee before it hits the external API.

Build vs. Stripe Connect: when custom wins

Use Stripe Connect directly for most marketplace builds. The hosted seller onboarding, the built-in KYC flow, and the webhook infrastructure save 4-6 weeks of engineering time. The 0.25% + $0.25 per payout fee is reasonable at low GMV.

Custom payment infrastructure wins in three situations.

Your GMV exceeds $5M per year. At $5M GMV with Stripe's standard pricing, you pay approximately $150,000 in processing fees annually. A custom payment layer built on a negotiated Stripe agreement or on Adyen can cut that by 30-50%. The savings fund the build cost in year one.

You need payout controls Stripe Connect does not offer. Seven-day rolling escrow with dispute windows. Seller credit lines secured against future earnings. Multi-currency payouts with custom FX rules. Tiered platform fees that change based on seller volume. These require custom ledger logic that Stripe Connect cannot configure.

You are building a white-label payment product. If your business model involves selling payment infrastructure to other businesses under their brand, you need your own platform. You cannot white-label Stripe Connect.

Do not build custom for standard SaaS subscription billing. Stripe Billing handles tax, dunning, proration, and checkout better than anything you would build in 3 months. Use it.

Do not build custom if your platform is pre-revenue. Stripe Connect with no custom layer gets you to market faster. Optimize the cost after you have proven the model.

How RaftLabs can help

RaftLabs has built payment infrastructure for marketplace platforms and fintech products. We understand the double-entry ledger requirement. We have built idempotency systems that survive production edge cases. We have integrated Stripe Connect, Plaid, and Adyen in marketplace contexts where the split logic and escrow rules were specific to the client's business model.

The first step is understanding your specific payment model: how many parties are involved, what the split rules are, whether you need escrow, and what your GMV looks like today and in 18 months. The answers to those questions drive the architecture.

We will give you a realistic cost range and timeline before any commitment. If Stripe Connect direct is the right answer for your current stage, we will tell you that too.

Book the scoping call