What a payment processing app actually does

A payment processing app moves money from one account to another and records that movement. It does not create money or decide who gets paid—it sits between a customer, a merchant or service provider, and the financial institutions that hold the actual accounts. Your app will handle the request, validate it, send it to a payment network or bank, wait for approval or rejection, and then tell both sides what happened.

The work breaks into three layers: the front end (what users see and touch), the backend (where transactions are validated and routed), and the connections to payment networks and banks (where the actual money moves). Most builders underestimate the third layer because it is invisible to users but it is where most of the complexity and cost lives.

Key Takeaways

  • Payment processing requires connections to banks and payment networks, not just a database—you cannot build this entirely on your own infrastructure.
  • You will need a payment processor (like Stripe or Square) or a payment gateway (like Authorize.Net) to accept cards; direct bank connections require a separate acquiring bank relationship.
  • PCI DSS compliance is mandatory if you touch card data, and the easiest path is to use a processor that handles it for you rather than building your own compliance.
  • Transaction fees vary by payment method and processor, ranging from 2.2% plus $0.30 per card transaction to flat monthly rates for ACH or wire transfers.
  • Settlement—the actual movement of money into your account—takes one to three business days after a transaction is approved, not instantly.

Choose between a processor, a gateway, or building your own acquiring relationship

A payment processor (Stripe, Square, PayPal) handles everything: they connect to card networks, manage compliance, hold your money temporarily, and deposit it into your bank account. You integrate their API, send transaction details, and they return approval or decline. You pay a percentage of each transaction plus sometimes a flat fee per transaction. This is the fastest path to launch and the one most startups take.

A payment gateway (Authorize.Net, First Data) validates and routes transactions but does not hold the money—it passes the request to your acquiring bank. You need a separate relationship with an acquiring bank, which means more paperwork, higher minimums, and more direct responsibility for compliance. Gateways are cheaper per transaction if you have volume, but the setup is slower and the support burden is on you.

Building your own acquiring relationship means becoming a merchant services provider yourself. You sign directly with Visa, Mastercard, and your acquiring bank. This requires significant capital, compliance infrastructure, and legal setup. Unless you are processing millions per month, this is not economical—the processors already exist because the barrier to entry is intentionally high.

Understand PCI DSS and why you probably should not handle card data directly

PCI DSS (Payment Card Industry Data Security Standard) is a set of security requirements that apply to anyone who stores, processes, or transmits credit card data. There are four compliance levels based on transaction volume, and even Level 4 (the lowest, for fewer than 20,000 transactions per year) requires annual security assessments, encryption, firewalls, and documented procedures.

The practical path for most apps is to never touch card data at all. Use a processor's hosted payment form or tokenization: the customer enters their card on a page you do not control, the processor returns a token, and you store and use the token instead of the card number. This moves PCI responsibility to the processor, which has already invested in compliance. If you build your own card form, you inherit full PCI responsibility and the cost of annual audits and penetration testing.

Some processors offer PCI compliance as a service—they handle the audit and documentation in exchange for a higher per-transaction fee or a monthly compliance fee. This is worth the cost if you are not processing enough volume to justify a dedicated compliance officer.

Build the core transaction flow: request, validation, routing, settlement

Every transaction follows the same sequence. First, the user submits payment details (card, bank account, digital wallet, or other method) through your app. Your backend receives the request and validates it: is the amount positive, is the currency supported, does the customer exist, is there a reason to block this transaction (fraud rules, velocity checks, blacklists).

Next, your app sends the validated request to your processor or gateway. The processor checks with the card network or bank, which checks with the customer's bank (the issuer). The issuer approves or declines based on available funds, fraud rules, and other factors. This round trip typically takes one to three seconds. Your processor returns the result to your app, and your app stores the transaction record and tells the user whether it succeeded.

Settlement happens later—usually the next business day or the day after. The processor batches all approved transactions, nets them against refunds and chargebacks, and deposits the total into your bank account. You do not control this timing; it is set by the processor and the banks involved. During this window, the money is in limbo—the customer's bank has deducted it, but you have not received it yet.

Handle the payment methods your users actually need

Credit and debit cards are the default, but they are not the only option. ACH transfers (bank account to bank account within the US) are slower (three to five business days) but cheaper (often $0.25 to $1.00 per transaction). Wire transfers are faster (same day in some cases) but more expensive ($15 to $50 per transaction) and require more customer information. Digital wallets (Apple Pay, Google Pay, PayPal) are fast and reduce friction because the customer does not re-enter their card.

Each method requires a separate integration. Card processing goes through one network, ACH through another, wire transfers through yet another. Most processors bundle several methods, but not all. If you need ACH and cards, verify that your processor supports both before you commit. Some processors specialize in one method and charge more for others.

International payments add another layer: currency conversion, cross-border regulations, and different payment methods by country (SEPA transfers in Europe, local bank transfers in Asia). If you need this, choose a processor with international reach—Stripe and PayPal have it, but smaller processors may not.

Plan for refunds, disputes, and what happens when transactions fail

A refund is a reversal initiated by you. The customer received the service or product and you decide to return the money. Refunds are usually processed within one to three business days and appear in the customer's account as a credit. You can refund a transaction only if it settled; you cannot refund a transaction that is still pending.

A chargeback is a reversal initiated by the customer's bank. The customer claims they did not authorize the transaction, did not receive the goods, or received something different from what was promised. The bank pulls the money back from you and opens an investigation. You can dispute the chargeback by providing evidence (order confirmation, shipping proof, communication with the customer), but the burden is on you to prove the transaction was legitimate. Chargebacks take weeks to resolve and cost you a fee ($15 to $100 per chargeback) even if you win.

Build your app to handle failed transactions gracefully. A transaction can fail for many reasons: insufficient funds, incorrect card details, fraud blocks, network errors, or the processor being temporarily unavailable. Your app should retry certain failures automatically (network errors, temporary blocks) and ask the user to try again or use a different payment method for others (insufficient funds, invalid card). Log every failure so you can debug patterns.

Calculate your costs and choose a pricing model

Payment processing is not free. Costs vary by processor, payment method, and transaction volume. A typical card transaction costs 2.2% of the amount plus $0.30 per transaction with Stripe or Square. ACH costs $0.25 to $1.00 per transaction. Wire transfers cost $15 to $50. Some processors charge a monthly minimum or a monthly fee on top of per-transaction fees.

You will also pay for infrastructure: servers to run your app, databases, monitoring, and backups. You may pay for fraud detection tools, compliance audits, and customer support. Add these costs together and decide how to pass them to your users. Some apps absorb the cost (the merchant or service provider pays it). Others pass it to the customer (a fee appears at checkout). Some split it. Your choice affects how competitive you are and how much margin you keep.

Build a cost model before you launch: estimate your transaction volume, multiply by your processor's fees, add your infrastructure costs, and see whether the margin is sustainable. If your margin is too thin, you will run out of money before you reach scale.

Frequently Asked Questions

Do I need to build my own payment processing from scratch?

No. Use an existing processor (Stripe, Square, PayPal) or gateway (Authorize.Net). Building your own acquiring relationship is only worth it if you are processing millions per month and have significant capital and compliance resources. For most startups, the processor handles the hard parts and you focus on your product.

What is the difference between a processor and a gateway?

A processor handles everything: they connect to banks, manage compliance, and deposit money into your account. A gateway only validates and routes transactions—you need a separate acquiring bank relationship. Processors are easier to set up; gateways are cheaper per transaction at high volume.

How long does it take to get paid after a transaction?

Settlement usually takes one to three business days. The customer's bank deducts the money immediately, but your processor batches transactions and deposits them later. You cannot control this timing; it is set by the processor and the banks.

Can I accept payments without handling card data?

Yes, and you should. Use your processor's hosted payment form or tokenization so the customer enters their card on a page you do not control. The processor returns a token and you store the token instead of the card number. This avoids PCI compliance responsibility.

What happens if a customer disputes a transaction?

The customer's bank opens a chargeback investigation and pulls the money back from you. You can dispute it by providing evidence (order confirmation, shipping proof, communication), but the burden is on you to prove the transaction was legitimate. Chargebacks cost you a fee even if you win.