What integration means and why platforms do it

Payment integration means connecting your platform directly to the systems that move money and issue cards, so your users can pay, receive funds, or hold a card without leaving your app or website. You are not building a payment system yourself — you are plugging into existing infrastructure run by banks, payment networks, and specialized processors.

A marketplace might integrate payments so sellers get paid automatically when a buyer completes a purchase. A fintech app might integrate card issuing so users can spend their balance when ready without waiting for a physical card to arrive. A platform for gig workers might integrate both: payments flowing in from customers, and a card so workers can access their earnings on demand.

The reason platforms do this is speed and control. Without integration, your users have to move money manually between your platform and their bank account — a friction point that costs you engagement and them time. With integration, the money flow is invisible to them.

Key Takeaways

  • Payment integration connects your platform to banks and processors so money moves directly between users without manual transfers.
  • Card issuing requires a partnership with a bank that holds the actual account, plus a processor that manages the card network connection.
  • You choose between white-label solutions (a vendor handles most of the infrastructure) and building on top of APIs (you handle more of the logic).
  • The regulatory burden depends on what you do: moving money between your users is lighter than holding their funds yourself.
  • Integration timelines range from weeks for straightforward payment flows to months for card issuing, because banks move slowly and compliance reviews are thorough.

The difference between payment processing and card issuing

Payment processing is the plumbing that moves money from one account to another — usually from a customer's bank account or card to a merchant's account, or between two users on your platform. You are facilitating a transaction that already exists; the money is already in the system somewhere.

Card issuing is different. You are creating a new card product that your users hold and use to spend money. That card is backed by an actual bank account — usually held at a partner bank — and connected to the card networks (Visa, Mastercard, American Express). When your user swipes the card, the transaction flows through those networks to the issuing bank, which deducts the money from their account with you.

A platform might do one or both. A peer-to-peer payment app does payment processing only — it moves money between users' existing bank accounts. A neobank or fintech wallet does card issuing — it creates a card product and holds the underlying account. A marketplace might do both: process payments between buyers and sellers, and issue a card so sellers can access their earnings.

The infrastructure is different, the regulatory requirements are different, and the partnerships you need are different. Payment processing is lighter to build; card issuing requires a banking partner and takes longer to launch.

How payment processing integration works

Payment processing on your platform usually means connecting to an ACH processor (for bank-to-bank transfers in the US), a card processor (for credit and debit card transactions), or both. The processor sits between your platform and the banking system, handling the technical details of moving money and managing the risk.

Here is the basic flow: a user initiates a payment on your platform. Your platform sends the payment details to the processor's API — the account to debit, the account to credit, the amount, and the reason. The processor validates the request, checks for fraud, and sends it into the banking network. The money moves (usually within one to three business days for ACH, when ready for card transactions). The processor sends a confirmation back to your platform, which you show to the user.

You do not hold the money yourself in this model. The processor or the underlying bank holds it briefly in transit, but your platform is just the interface. This is why payment processing is lighter to build than card issuing — you are not a money transmitter in the regulatory sense, because you are not holding customer funds.

Common processors for this are Stripe, Square, Plaid (for ACH), and Wise (for international transfers). Each has an API you integrate with, documentation you follow, and compliance requirements you meet. The processor handles the banking relationships; you handle the user experience and the business logic of when to trigger a payment.

How card issuing integration works

Card issuing is more complex because you need three separate relationships: a partner bank that holds the actual account and is the legal issuer of the card, a card processor that manages the connection to Visa or Mastercard, and usually a card manufacturer that prints and ships the physical card.

The flow works like this: a user opens an account on your platform. Your platform sends their information to the partner bank through an API, and the bank creates a deposit account in their name. Your platform then requests a card from the card processor, which generates a card number, expiration date, and CVV tied to that account. The processor connects that card to the Visa or Mastercard network. When the user makes a purchase, the transaction flows through the network to the processor, which debits the account at the partner bank, and the processor confirms the transaction back to the merchant.

You are responsible for the user interface — the app where they see their balance, request a card, and view transactions. The partner bank is responsible for holding the money and being the legal issuer. The processor is responsible for the technical connection to the card networks. This split of responsibility is why card issuing takes longer to launch — you need all three parties aligned, and banks move slowly.

Common card issuing platforms are Marqeta, Galileo, Lithic, and Stripe Issuing. Each has different pricing, different feature sets, and different partner banks they work with. Some are white-label (they handle most of the infrastructure and you just customize the user experience); others are more API-driven (you build more of the logic yourself).

White-label versus API-first integration

A white-label solution means a vendor provides the entire infrastructure — the account opening, the card issuance, the transaction processing, the compliance — and you customize the user interface and branding. You are essentially renting their platform and putting your logo on it. This is faster to launch but gives you less control over the details.

An API-first integration means you build more of the logic yourself on top of the vendor's core infrastructure. You call their APIs to create accounts, issue cards, process transactions, and handle disputes. This takes longer but gives you more flexibility to build exactly what your users need.

Most platforms start white-label to get to market quickly, then move toward API-first as they grow and need more customization. A small marketplace might use Stripe's white-label payment processing; a larger one might build custom logic on top of Stripe's APIs. A neobank might start with a white-label card issuing platform and later switch to a processor like Marqeta to build their own account opening and card management flows.

The choice depends on your timeline, your engineering resources, and how different your product needs to be from the standard offering. If you need to launch in weeks, white-label is faster. If you need to build something the vendors do not offer, API-first is necessary.

Regulatory and compliance requirements

The regulatory burden depends on what you do. If you are just processing payments between existing accounts (payment processing), the burden is lighter — you are not a money transmitter, and the processor handles most of the compliance. You still need to verify user identity, screen for fraud, and follow anti-money-laundering rules, but the processor usually provides the tools.

If you are holding customer funds or issuing a card (card issuing), the burden is heavier. You may need a money transmitter license in each state where you operate, depending on how the partnership is structured. The partner bank is usually the licensed entity, but you may still need to register. You will need to implement Know Your Customer (KYC) checks — verifying that users are who they say they are — and Anti-Money Laundering (AML) monitoring, which means flagging suspicious transaction patterns.

The processor or partner bank usually provides the compliance infrastructure — the tools to verify identity, the monitoring systems, the reporting to regulators. Your job is to use those tools correctly and understand what you are responsible for. This is why integration timelines are long: banks and regulators move slowly, and compliance reviews can take months.

Before you start building, talk to a lawyer who understands fintech. The regulatory landscape varies by state and by what you are doing, and getting it wrong is expensive.

Timeline and cost expectations

Payment processing integration typically takes two to eight weeks, depending on the processor and how complex your use case is. A straightforward payment flow — customer pays merchant — is faster. A complex one — payments between multiple parties with splits and holds — takes longer. Costs are usually per-transaction fees (1 to 3 percent) plus monthly minimums, depending on volume.

Card issuing integration typically takes three to six months. This is not because the technical work is harder; it is because banks move slowly. You need to negotiate a partnership agreement with the issuing bank, pass their compliance review, integrate their APIs, test extensively, and get regulatory approval. During this time you are not generating revenue, so the cost is mostly your engineering time and the processor's setup fees (usually a few thousand dollars).

Once live, card issuing costs are per-card fees (usually 50 cents to a few dollars per card per year), per-transaction fees (much lower than payment processing, often free), and fees for physical card production and shipping. Payment processing costs are purely per-transaction.

Budget for longer timelines if you are in a heavily regulated space (financial services, gambling, cannabis) or if you need features the standard vendors do not offer. Budget for shorter timelines if you are using a white-label solution and your use case is standard.

Choosing a processor or issuer

The main decision is whether to use a single vendor that does both payment processing and card issuing, or to use separate vendors for each. Stripe, Square, and Wise do payment processing; Stripe Issuing, Marqeta, and Galileo do card issuing. Some platforms use Stripe for both; others use Stripe for payments and Marqeta for issuing.

The trade-off is simplicity versus flexibility. A single vendor is simpler — one integration, one support relationship, one set of APIs to learn. Separate vendors give you more flexibility — you can choose the best processor for payments and the best issuer for cards, even if they do not work together perfectly.

Before you choose, talk to the vendor about your specific use case. Ask about their partner banks (especially important for card issuing — not all banks work with all processors). Ask about their compliance requirements and timeline. Ask about pricing at your expected volume. Ask about their API documentation and support. The vendor you choose will shape your product for years, so choose carefully.

Frequently Asked Questions

Do I need a banking license to integrate payments or issue cards?

Not usually, if you partner with a bank that holds the account and is the legal issuer. The bank is licensed; you are not. However, you may need a money transmitter license in some states, depending on how the partnership is structured. Talk to a lawyer before you start building.

How long does it take for money to move between accounts after a payment is initiated?

ACH transfers (bank-to-bank) usually take one to three business days. Card transactions settle when ready to the merchant but may take a day or two to appear in the customer's account. International transfers can take longer depending on the corridors and banks involved.

What happens if a transaction fails or a user disputes a charge?

The processor handles the technical failure — they will retry or return an error code to your platform. For disputes, the processor has a dispute management system where the customer can contest a charge. You handle the customer service; the processor handles the banking side. Most processors provide a dashboard where you can see disputes and respond to them.

Can I use multiple processors at the same time?

Yes, many platforms do. You might use Stripe for credit card payments and Plaid for ACH transfers, or Stripe for payments and Marqeta for card issuing. The trade-off is complexity — more integrations to maintain, more compliance reviews, more support relationships. Most platforms start with one and add others as they grow.

What compliance checks do I need to do on my users?

At minimum, you need to verify their identity (name, address, date of birth) and check them against sanctions lists. The processor usually provides the tools for this. For higher-risk use cases (large transfers, international payments, financial services), you may need deeper checks like income verification or source-of-funds documentation. The processor will tell you what they require.