Card Issuing Architecture: Processors, BIN Sponsors, JIT Funding and Authorization Flow (2026)

Disclaimer: this article is a systems and architecture analysis, not legal, regulatory, financial or investment advice. Regulations, network rules and vendor behaviour change; verify against current primary sources before building or contracting.

A card swipe looks like one event and is in fact four or five separate systems agreeing, within a few seconds, on a decision that will not be financially final for days. If you are building a spend-management product, a neobank, an expense card or an embedded-finance feature, the hard part is not the card artwork. It is the card issuing architecture underneath it: who holds the licence, who holds the BIN, who answers the network at 2 a.m., and where your own ledger sits in that chain.

This matters more in 2026 than it did five years ago. Issuer processors now expose real-time decisioning to ordinary product teams, so a webhook you wrote on Tuesday can decide whether a customer’s lunch is declined on Wednesday. This guide takes you through the roles, the authorization message flow, just-in-time (JIT) funding, the clearing and settlement timeline, tokenization, PCI scope, disputes, and the failure modes that actually page people.

What this covers: the four-party model and where issuer processors, program managers and BIN sponsors fit, the authorization sequence and the ISO 8583 fields involved, JIT funding and its latency budget, stand-in processing, clearing, settlement and interchange, ledger entries per lifecycle step, PCI DSS scope, tokenization, disputes, and a practical build checklist.

Context and Background

Card networks such as Visa and Mastercard run what the industry calls the four-party model: a cardholder, a merchant, an acquirer that serves the merchant, and an issuer that serves the cardholder. The network sits between acquirer and issuer, routing messages and defining the rules. In the classic bank-issued world, one institution was the issuer: it held the licence, owned the BIN range (the leading digits of the card number that identify the issuer), ran the processing stack and carried the credit or deposit risk.

Modern programs unbundle that single institution into layers. A BIN sponsor bank is a regulated bank that is a member of the card network, holds the network licence and is the issuer of record. An issuer processor is the technology platform connected to the networks that authorizes transactions, manages card state, produces clearing files and exposes APIs. A program manager is the company that designs the card product, owns the customer relationship and carries much of the day-to-day compliance burden under the sponsor’s oversight. In many fintech stacks the program manager and the API-first processor are sold as one bundle, which blurs the picture, but the legal and technical responsibilities remain distinct.

Why does this layering exist? Network membership and bank charters are expensive and slow, while software is cheap and fast. Sponsor banks rent out regulatory standing and settlement rails; processors rent out connectivity and decision engines; program managers bring a product. Programs in the US run under bank oversight and have drawn heightened regulatory attention in recent years, so the sponsor relationship is a real operational dependency, not a formality. Treat any statement about specific enforcement or rule changes as something to verify against current regulator publications.

On the wire, authorization traffic between acquirers, networks and issuers is built on ISO 8583 message structures, with each network publishing its own specification and field usage. If the message-level details are new to you, our deep dive on ISO 8583 versus ISO 20022 card messaging formats for authorization and clearing covers the format differences. For the formal reference on card-data security you will also meet the Payment Card Industry Data Security Standard from the PCI Security Standards Council, which we return to in the PCI section.

Two further vocabulary points save confusion later. Authorization is the real-time yes or no, and it reserves value without moving money. Clearing is the later exchange of final transaction details, and settlement is the movement of net funds between institutions. A great deal of card-program design is the art of keeping those three events, which happen at different times, consistent inside one ledger.

Reference Architecture: Who Owns What in a Card Program

In one paragraph: a card program has four technical planes. The network plane (Visa, Mastercard) routes messages. The processor plane authorizes, manages card state and produces clearing. The sponsor plane provides the BIN, the licence and the settlement account. The product plane, which you own, holds customers, rules, the ledger and often the JIT funding decision. Your architecture is the contract between those planes.

Figure 1: Roles and message paths in a modern card issuing architecture. Solid arrows are transaction messages; the dotted line is the contractual and compliance relationship between program manager and sponsor bank.

The figure shows the core point: money and messages take different paths. Authorization messages travel from merchant to acquirer to network to your issuer processor, and the answer returns the same way. The contractual authority, however, flows from the network licence to the sponsor bank, and from the sponsor to the program manager. That mismatch is why a feature decision in your product can trigger a sponsor-bank review.

The issuer of record is the sponsor bank. Its name is on the BIN registration with the network, it is liable to the network for rule violations, and it holds the funds that back the program, either in a for-benefit-of (FBO) account or on its own balance sheet depending on the product. When people say “who is the issuer,” the answer has two layers: legally the bank, operationally the processor and program manager.

The issuer processor does the heavy real-time and batch work. In real time it receives the network authorization, validates the card number, expiry, PIN or cryptogram and card status, applies spend controls, calls your decision webhook if you use JIT funding, and returns the response. In batch it ingests clearing files, matches them to prior authorizations, posts final amounts, and generates settlement reports and fee data. Modern API-first processors such as Marqeta and Lithic expose this surface as REST APIs and webhooks, and legacy processors do it through batch files and host-to-host interfaces. Product names change quickly; verify current capabilities in vendor docs.

The program manager is where fintech product teams usually live. It defines card products, funding models, KYC and onboarding flows, fraud rules, customer support and dispute handling. Under most sponsor agreements, program managers must run a compliance program the sponsor can audit: complaint handling, marketing review, transaction monitoring, and anti-money-laundering controls. Sponsors typically retain the right to approve or veto product changes.

Funding models: prefunded, credit and JIT

There are three common ways the available balance is decided at authorization time. In a prefunded or stored-balance model, the processor holds a balance per card or per account and checks it directly. Simple, but it means funds sit with the processor or sponsor before they are needed. In a credit or revolving model, the issuer extends a credit line and the processor checks it. In a JIT funding model, the processor holds no balance logic of its own for the card. Instead, it forwards each authorization to your gateway and you decide, using your own ledger, whether to approve. If you say yes, the program funding account is debited just in time to cover the transaction.

JIT funding is attractive because the balance of truth lives in your system. Corporate cards can enforce per-department budgets, a marketplace can pay out from a wallet at the moment of spend, and a neobank can combine multiple sources of funds, all without pre-allocating money to each card. The cost is a hard real-time dependency: if your gateway is slow or down, cards stop working.

The ledger that makes it all consistent

Underneath every card program is a ledger. Authorization places a hold; clearing converts the hold into a posted debit at the final amount; settlement reconciles net funds with the sponsor. Each step is a state transition, and each is naturally an immutable event. That is why card programs pair well with the patterns in our guide to event sourcing and bitemporal data for financial audit trails: a transaction’s life is a sequence of facts about different times (when the authorization happened, when it cleared, when you learned of it), and a bitemporal model keeps those straight when clearing arrives days late or a dispute reverses history.

The Card Authorization Flow, Message by Message

In one paragraph: the card authorization flow starts when a merchant terminal or e-commerce gateway sends a request to its acquirer, which formats an ISO 8583-style message and sends it to the network. The network routes it to the issuer processor by BIN, the processor validates and, with JIT funding, calls your gateway, and the response retraces the path. The whole round trip is typically completed in a few seconds.

Figure 2: Authorization sequence with a JIT funding gateway. The gateway decision is on the critical path of every purchase.

Request: what the issuer processor receives

The authorization request is conceptually an ISO 8583 message with a message type indicator (MTI) and a bitmap that declares which data elements follow. Authorization requests are generally in the 0100 family (authorization) or the 0200 family (financial request, used for single-message debit and PIN transactions); responses use 0110 and 0210 respectively. Reversals use the 04xx family. Networks implement their own dialects, so treat the field list below as the common conceptual core, not a spec.

Data element	Meaning	Why the issuer cares
DE 2	Primary account number (PAN)	Identifies card and BIN for routing
DE 3	Processing code	Purchase, cash, refund, balance inquiry
DE 4	Transaction amount	The amount to hold
DE 7	Transmission date and time	Ordering and replay detection
DE 11	System trace audit number	Matches request to response
DE 18	Merchant category code (MCC)	Spend controls by merchant type
DE 22	POS entry mode	Chip, contactless, magstripe, keyed, e-commerce
DE 37	Retrieval reference number	Cross-reference through clearing
DE 39	Response code (in response)	Approve or decline reason
DE 41 / 42 / 43	Terminal, merchant ID, name and location	Merchant matching, descriptors, risk
DE 49	Transaction currency	FX handling
DE 55	EMV chip data	Cryptogram validation

Notice what is not here: your customer’s name, balance, or account. The processor maps the PAN to a card token and an account in its own database, and only then can it talk about your customer in webhook terms.

Validation inside the processor

Before your code runs, the processor performs the checks only it can: PAN and BIN lookup, expiry, card status (active, suspended, terminated), PIN verification where relevant, and cryptographic validation. For chip transactions the issuer validates the application cryptogram carried in the EMV data; for e-commerce it may validate a network token cryptogram or run 3-D Secure authentication as a separate flow. These checks decide whether the request even reaches the funding stage.

Processors also apply configured controls, such as per-transaction limits, MCC allow or block lists, velocity limits and country restrictions. The order matters: cheap, local checks run first so that the expensive external call to your gateway is made only for requests that could plausibly succeed. This is also your first latency optimisation: push every rule the processor can enforce natively into processor configuration rather than into your webhook.

The JIT funding decision

With JIT funding, the processor sends your gateway an HTTP request containing the transaction amount, currency, merchant data, card token, and often a running view of related events. Your gateway answers approve or decline. In Marqeta’s documented design, the gateway must respond within three seconds; if it does not, Marqeta declines the transaction to the network and sends a webhook with a timed-out flag so you can reverse any authorization your system later completes. An approval is HTTP 200 and a decline is HTTP 402 in that model (Marqeta timeout guide). Other processors use different protocols and budgets, so confirm yours.

A good gateway does five things in this order. It authenticates the request, typically through HMAC signatures or mutual TLS. It deduplicates by transaction token so a retry never double-holds. It reads the customer’s available balance and the relevant policy. It writes a hold atomically with a conditional check so concurrent authorizations cannot overspend. And it returns the response, then performs slower side effects such as notifications asynchronously.

Response and what the network does next

The processor translates your decision into an ISO 8583-style response with a response code in DE 39, with 00 conventionally meaning approved, and common decline codes including 05 (do not honor), 51 (insufficient funds) and 91 (issuer or switch unavailable). Mapping your internal decline reasons to the right network code matters because merchants and acquirers use it for retry logic: a 51 might prompt a customer to use another card, while a 91 may cause an automatic retry later. Returning 05 for everything hides useful signal and costs the cardholder approvals.

The network forwards the response to the acquirer, which relays it to the merchant. An approval carries an approval code in DE 38 that later appears in clearing. At this instant no money has moved between institutions. A hold exists, the cardholder’s available balance is lower, and a clock has started for the merchant to submit the final amount.

Deeper Analysis: JIT Latency Budgets, Clearing, Settlement and the Ledger

In one paragraph: the JIT funding decision is bounded by a timeout set by your processor (three seconds in Marqeta’s documentation), which is itself nested inside a tighter, network-defined window. Your real budget is therefore whatever remains after network transit, processor validation and safety margin. After approval, the transaction lives on through clearing and settlement, and your ledger must track each stage.

A latency budget you can actually design to

The network does not publish a friendly number you can plan around, and networks and acquirers apply their own timers, so treat any figure below as an illustrative budget, not a specification. What is documented is the processor-level limit: Marqeta states its JIT gateway must respond within three seconds. Work backwards from that. Network and acquirer hops, TLS, and processor validation consume part of the window. Your gateway should aim for a p99 well below the limit, because the penalty for crossing it is a hard decline of an otherwise valid purchase.

Segment (illustrative)	Budget	Notes
Processor to gateway network transit	20-60 ms	Same cloud region as the processor if possible
TLS and request parsing	5-15 ms	Keep connections warm, use HTTP keep-alive
Idempotency check	2-5 ms	Key-value store lookup by transaction token
Balance and policy read	5-20 ms	Cache policy, read balance from the primary
Atomic hold write	10-40 ms	Single conditional write, no distributed transaction
Response serialisation and return	5-15 ms	Do not log synchronously
Target p99 total	under 300 ms	Leaves roughly 10x headroom to a 3 s limit

These numbers are design targets chosen to illustrate the shape of the budget, not measurements. The point is the headroom: a p99 of 300 ms against a 3,000 ms limit means a slow database failover or a garbage-collection pause does not translate directly into declined purchases.

The hold-atomicity problem

The most common JIT bug is a race. Two authorizations for the same customer arrive within milliseconds, each reads a balance of 100, each approves 80. Without an atomic check, you have approved 160 against 100. The fix is a conditional write, expressed as “decrement available balance by amount if available balance is at least amount,” executed as one operation on one partition. In SQL this is an UPDATE with a WHERE clause on balance and a check on rows affected; in a key-value store it is a conditional update or compare-and-set. Distributed transactions across services do not belong in this path.

If funds live in multiple pockets (for example department budget plus company wallet), keep the decision local by modelling a single authorization account per card or per spend group whose balance is replenished asynchronously. The real-time path touches one row; replenishment and allocation run in the background.

Message pairs: single-message versus dual-message

Networks distinguish two flows. In dual-message flows (typical for signature credit and many debit transactions), the authorization is one message and the financial capture is a later clearing message, usually in a batch. In single-message flows (typical of PIN debit and ATM), the authorization and financial posting are the same message and the transaction is financially final at approval. Marqeta’s ledger-management guidance reflects exactly this: for dual-message transactions you place a temporary hold on approval, receive a pending notification, and release the hold and complete the cash movement when the clearing webhook arrives; for single-message transactions you place the hold at approval and finalise it when the completed transaction webhook arrives (Marqeta ledger management with JIT funding).

Authorization, clearing and settlement on one timeline

Figure 3: Lifecycle of a card transaction. Authorization takes seconds; clearing typically arrives within hours to days; settlement nets funds between institutions; disputes can reopen the transaction weeks or months later.

Authorization takes seconds and produces a hold. Clearing follows when the merchant submits the transaction for capture, often at end of day, though hotels, car rental, fuel and tipping merchants can submit amounts that differ from the authorized amount, or submit several clearings against one authorization. The processor matches each clearing record to prior authorizations using identifiers such as the approval code, retrieval reference number and network transaction ID. Matching is a heuristic in many edge cases, which is why unmatched or “orphan” clearings are a standing operational queue.

Settlement is the movement of net funds. Each network produces settlement positions between acquirers and issuers, and the sponsor bank settles with the network through its settlement account, typically daily, with timing depending on network, currency and business-day calendar. Your program funding model determines how the sponsor is made whole: in a prefunded model the money is already at the sponsor; in a JIT model you typically fund the sponsor-held program account on a schedule, so your treasury must forecast settlement obligations against intraday spend.

Interchange: where the fee money goes

Every purchase carries an interchange fee, paid by the acquirer side to the issuer side, with the rate set by the network’s published schedules and varying by card type, merchant category, region and entry mode. The issuer’s share is what funds rewards, fraud losses and program manager revenue share. In the US, debit interchange for issuers above a size threshold has been capped under the Federal Reserve’s Regulation II (the Durbin amendment), while issuers below that threshold are exempt from the cap and typically earn more per transaction; this is one reason small sponsor banks are attractive to debit programs. The cap level and its calculation have been under review and subject to rulemaking and litigation, so check the Federal Reserve’s current Regulation II publications rather than relying on figures remembered from earlier years.

Architecturally, interchange appears in clearing data and in network fee reports. Your ledger should record the gross purchase, the interchange earned, network and processor fees, and any revenue share as separate postings, because they arrive from different sources on different days and reconcile to different invoices.

Worked example: ledger entries per lifecycle step

Here is an illustrative dual-message purchase: a 100.00 dollar charge that later clears at 100.00 plus a 12.00 tip, with a hypothetical 1.80 percent interchange rate on the cleared amount. All numbers are illustrative.

Step	Event	Ledger effect
1	Authorization approved for 100.00	Dr customer available 100.00 / Cr authorization holds 100.00
2	Pending webhook	No change, hold stays
3	Clearing arrives for 112.00	Reverse hold 100.00; Dr customer posted 112.00 / Cr settlement payable 112.00
4	Interchange earned 2.02 (112.00 x 1.80%)	Dr interchange receivable 2.02 / Cr interchange revenue 2.02
5	Settlement	Dr settlement payable 112.00 / Cr sponsor program account 112.00
6	Later dispute, full amount, provisional credit	Dr dispute receivable 112.00 / Cr customer posted 112.00

Step 3 is where naive systems break. The cleared amount exceeds the authorized amount, and the extra 12.00 may exceed the customer’s available balance. Many networks permit merchants such as restaurants to clear above the authorized amount within defined tolerances, so the issuer must either absorb the overage or collect it afterwards. A program that pretends clearing always equals authorization will eventually show negative balances.

Stand-In Processing, Tokenization and PCI Scope

In one paragraph: when an issuer processor cannot reach your gateway, it can fall back to stand-in logic using cached limits or balances, or it can decline. Separately, tokenization replaces card numbers with network tokens in wallets and e-commerce, and PCI DSS scope depends on whether your systems store, process or transmit cardholder data. Good architecture minimises all three exposure surfaces.

Stand-in processing

Networks operate their own stand-in service (Visa calls its version Stand-In Processing and Mastercard has an equivalent) that can answer on behalf of an issuer who is unreachable or exceeds the response time, applying parameters the issuer has pre-registered, such as maximum amounts and risk thresholds. Issuer processors have their own, earlier layer of fallback. The details differ by network, so verify the configuration options your sponsor and processor actually enable.

Figure 4: Failure handling. A gateway outage can end in a decline, or in a bounded stand-in approval that must be reconciled afterwards.

The design question is risk appetite. A decline-on-timeout policy is safe for credit exposure but harsh on customers: your outage becomes their embarrassment at a checkout line. A stand-in policy keeps cards working but exposes you to overspend. A sensible compromise is to allow stand-in only for low amounts, low-risk MCCs and customers with a strong recent balance history, using a conservative per-card cap and a velocity limit, and to reconcile every stand-in approval once your gateway recovers. Whatever you choose, document it in the sponsor agreement, because approving transactions your own ledger never saw is a financial and audit event.

Tokenization and wallet provisioning

Card numbers rarely travel raw anymore. In Apple Pay, Google Wallet and merchant-on-file scenarios, the PAN is replaced by a network token, a surrogate number mapped to the real PAN by the network’s token service. Your processor typically participates in provisioning: the wallet asks the network to create a token, the network asks the issuer processor to approve provisioning (green path, yellow path with step-up authentication, or red path decline), and the processor applies your rules. Each device-bound token has its own lifecycle state and cryptogram, so an authorization may arrive with a token PAN that the processor maps back to the funding PAN before calling you.

For your architecture this means two identifiers per card: the funding PAN (or its processor-side token) and one or more network tokens. Your gateway should key everything on the processor’s stable card token, never on a PAN, and your customer-facing history should show the same purchase regardless of which token was used. Provisioning decisions are an under-appreciated fraud surface: wallet-provisioning fraud, where an attacker adds a stolen card to their own phone, is a standing issuer concern, so yellow-path step-up and device signals deserve real investment.

PCI DSS scope and how to keep it small

The PCI Data Security Standard applies to any entity that stores, processes or transmits cardholder data, and to systems that could affect the security of that data. The standard’s current major version is 4.0.x; consult the PCI Security Standards Council for the exact revision and its effective dates. The cheapest way to handle PCI scope is to avoid touching the PAN at all.

In an API-first processor model this is achievable. The processor holds the PAN and CVV. Your systems receive card tokens, last four digits and metadata. Showing card details to a cardholder is done through processor-hosted components, such as iframes or SDK widgets that render the number directly from the processor, so your servers never see it. Keep it that way: logging a full request body in a debug path is how teams accidentally pull their entire platform into scope. For the logging side of this problem, our guide on PII detection and redaction pipelines for LLM applications applies the same principle of reversible tokenization at the boundary, and the pattern transfers directly to webhook payload logging.

Your sponsor bank will also want evidence of the processor’s own PCI compliance (typically an attestation of compliance) and may assess yours as a service provider if you handle any cardholder data. Do not assume the processor’s certification covers your own code.

Disputes and chargebacks

When a cardholder disputes a charge, the issuer files a dispute with the network, which routes it to the acquirer and then the merchant. The merchant may represent (contest) the chargeback with evidence, and unresolved cases can proceed to pre-arbitration and arbitration under network rules, with strict deadlines at each step. The networks publish dispute rules and reason codes in their rule books; consult those for current time limits, as they change.

From an engineering view, a dispute is another set of ledger events: a provisional credit to the customer where required, a chargeback receivable from the network, and a reversal if the merchant wins. Your system needs a case-management workflow, evidence storage that is access-controlled and retention-limited, and deadline tracking, because missing a network deadline typically forfeits the dispute. Processors expose dispute APIs and files, and your program manager team usually owns customer communication, subject to consumer protection rules such as Regulation E for debit cards in the US. Verify applicable liability and timeline rules for your jurisdiction with counsel.

Trade-offs, Gotchas, and What Goes Wrong

Card programs fail in boring, repeatable ways. Knowing the list in advance is most of the defence.

Your gateway is now a card network dependency. With JIT funding, every purchase calls your service. A deployment that adds 200 ms, a database failover that takes 15 seconds, or a certificate expiry is a customer-facing outage on every card at once. Run the gateway in at least two availability zones, keep it deliberately small, avoid synchronous calls to third parties inside the decision, and test certificate and secret rotation as a production drill.

Late approvals after a timeout. If your gateway completes work after the processor has already declined, you may hold funds for a purchase that never happened. Marqeta’s guidance is to check the timed-out flag on the gateway log and reverse the hold. Build that reversal path first, not last, and add a periodic sweep that releases holds with no matching pending or cleared event.

Duplicate and out-of-order events. Webhooks are at-least-once. Processors retry, networks send advice and reversal messages, and clearing can arrive before you process the pending notification. Key every ledger posting on a deterministic idempotency key, accept events in any order, and derive state from the full event history rather than from “the last message.” Marqeta notes that it does not link every scenario automatically, so related-transaction identifiers need to be stored and followed by your code.

Partial approvals and amount mismatches. Fuel pumps, hotels and restaurants authorize one amount and clear another. Support partial approval where the network allows it, tolerate over-clears within network rules, and decide in advance who bears the overage. Also handle incremental authorizations and multi-clearing, where one authorization yields several clearing records.

Multi-currency and FX. A purchase in a foreign currency arrives with the merchant’s currency in DE 49 and a billing-currency amount calculated by the network or processor. Your hold is in billing currency, but clearing may use a later rate. Reserve a buffer for FX drift, or accept that a small share of cleared amounts will exceed holds.

Over-reliance on stand-in. Stand-in keeps cards working but can create approvals your ledger did not decide. Without disciplined reconciliation, stand-in becomes unmanaged credit exposure. Cap it, monitor it and alert on it.

Sponsor-bank concentration. If your sponsor changes its risk appetite, restricts your program or runs into regulatory trouble, you cannot flip a switch and move BINs. Migrating a card portfolio between sponsors or processors means reissuing cards or negotiating a BIN transfer, which takes months. Many mature programs plan for a second sponsor or processor from early on, at least contractually, and keep card data portable through standard token migration procedures.

Fraud is a latency-sensitive workload. Rich fraud models want more data than a 300 ms budget allows. The usual pattern is a tiered design: cheap rules inline (velocity, MCC, geography), a precomputed per-card risk score refreshed asynchronously, and heavyweight analysis after the fact, with the ability to freeze a card in seconds when patterns emerge. Cross-rail fraud is increasingly relevant too: funds loaded to a card account through instant payment rails move faster than card chargeback timelines, a theme explored in our piece on instant-payments interoperability and fraud architecture across SEPA Instant, FedNow and RTP.

Regulatory and licensing drift. Rules on interchange caps, sponsor oversight, data protection and consumer liability differ by region and change over time. Treat compliance as an engineering input with an owner, not a legal afterthought.

Practical Recommendations

If you are about to design or re-platform a card program, the following sequence keeps the risky decisions early and the reversible ones late.

Start with the contract triangle, not the code. Confirm who the sponsor bank is, what the sponsor requires of program managers, what the processor guarantees for availability and latency, and what the exit terms are. A beautifully engineered gateway cannot rescue a programme whose sponsor can freeze it.

Decide the funding model by risk and product shape. If balances are simple and stable, a processor-held balance reduces your real-time risk. If your product needs flexible, multi-source or policy-driven spending, choose JIT funding and accept the operational burden that comes with it.

Design the gateway as a tiny, single-purpose service with a hard latency budget, a one-row atomic hold, idempotent handling and nothing else. Everything slow becomes asynchronous. Instrument the p50, p95 and p99 latency, the timeout count, and the decision mix per minute, and alert on changes in decline rate as well as on errors.

Make the ledger event-sourced from day one. Authorization, pending, clearing, reversal, settlement, interchange and dispute events should be append-only facts, with balances derived. This pays back during the first reconciliation incident, and again at audit time.

Keep PCI scope near zero by never handling PAN or CVV, by using processor-hosted card display, and by scrubbing logs at ingestion.

Checklist before launch:

Sponsor, processor and program manager roles written down, including who answers the network and who owns disputes.
Gateway p99 target set at a small fraction of the processor timeout, with load tests at three times peak.
Atomic conditional hold, idempotency keys and a timed-out hold reversal sweep implemented and tested.
Stand-in policy chosen, capped, documented with the sponsor, and reconciled automatically.
Clearing matching, orphan queue, over-clear and multi-clearing handling covered by tests.
Decline-code mapping reviewed so that “insufficient funds” and “do not honor” are not conflated.
Webhook signatures verified, secrets rotated on a schedule, and logs scrubbed of card data.
Dispute workflow with deadline tracking, evidence storage and provisional-credit rules reviewed with counsel.
Runbook for processor outage, sponsor outage and gateway outage, rehearsed at least once.

Frequently Asked Questions

A BIN sponsor is a licensed bank and network member that holds the BIN range and is the issuer of record, carrying regulatory and network liability. An issuer processor is a technology platform that connects to the networks, authorizes transactions, manages card state and produces clearing and settlement data on the issuer’s behalf. A fintech program typically needs both: the sponsor for legal standing and settlement, and the processor for real-time and batch processing.

What is JIT funding in card issuing?

Just-in-time funding means the issuer processor does not hold a balance for the card. Instead, for every authorization it calls your gateway, which decides in real time whether to approve based on your own ledger. If you approve, funds are reserved just in time. Marqeta documents a three-second gateway response limit and declines on timeout. JIT suits flexible, policy-driven spend but makes your gateway availability a payment-critical dependency.

How long does a card authorization take?

A typical authorization completes in a few seconds from tap or submit to approval, with most of that spent on network hops and issuer-side checks. Networks and processors enforce their own timers, and processors set stricter limits on your callbacks, such as Marqeta’s three seconds for JIT funding. Plan for a gateway p99 far below any documented limit, and confirm exact timeouts with your processor and sponsor, since they vary.

What is the difference between authorization, clearing and settlement?

Authorization is the real-time approval that places a hold on the cardholder’s available funds. Clearing is the later exchange of final transaction details, often in batch files, which converts the hold into a posted amount that may differ from the authorized one. Settlement is the net movement of money between acquirer, network, issuer and sponsor bank. Each stage needs its own ledger entries and reconciliation.

What happens if my JIT funding gateway goes down?

The processor will either decline transactions that time out, or, if configured and permitted by your sponsor, apply stand-in rules using cached limits to approve low-risk small purchases. Declining is safe but disruptive; stand-in preserves acceptance but creates exposure you must reconcile after recovery. Design for redundancy across zones, keep decisions simple, and reverse any hold created after a timed-out decline.

How can I keep PCI DSS scope small when issuing cards?

Avoid storing, processing or transmitting the PAN and CVV yourself. Use an issuer processor that holds card data and exposes tokens and last four digits to your systems, and render card details through processor-hosted components so your servers never see them. Scrub logs and webhook payloads, segment any systems that do touch card data, and obtain the processor’s attestation of compliance. Confirm your obligations with your qualified security assessor.

Comments

Leave a Reply Cancel reply

Tag Cloud

Categories