Issuer side · four-party model

Card issuer processing — and the acquirer-side orchestration that talks to it.

Every card authorisation is a conversation between the issuer side and the acquirer side, brokered by the scheme. topropay sits on the acquirer side, reading BIN and issuer behaviour per transaction to route across the connected acquiring panel for the best chance of issuer-side approval.

Book a routing review Read the API docs
Cardholder Merchant topropay Acquirer Scheme Issuer
Acquirer-side hub · scheme bridge · issuer authorises.
Four-party
model: issuer · scheme · acquirer · merchant
BIN-aware
routing per authorisation
Network tokens
VTS · MDES honoured by issuers
Decline-aware
cascade on soft declines

Four-party model

credit card issuer acquirer roles in the four-party card model

Four parties, two sides. Issuer and acquirer sit at opposite ends of every card authorisation, with the scheme bridging them.

Issuer
The bank or non-bank that issued the cardholder's card and runs the issuer-side card issuer processor stack — authorising or declining each transaction against the cardholder's account.
Scheme
Visa, Mastercard, Amex, Discover, JCB or RuPay — the network that carries the authorisation message from acquirer to issuer and back.
Acquirer
The licensed bank or institution holding the merchant's MID, sending the authorisation through the scheme to the issuer and receiving the response.
Merchant
The business taking the payment. With topropay's orchestration, the merchant integrates one API and the platform sits between them and the connected acquirers.

Key benefits

Why credit card issuer processing behaviour matters for routing

Four properties that show up the moment a merchant stops treating issuer behaviour as opaque and starts routing acquirer-side authorisations against it.

Read the issuer side, route the acquirer side

BIN look-ups identify the issuer for every card; the routing engine factors in per-issuer approval rates, regional acquiring fit and scheme-programme posture per acquirer before each authorisation.

Network tokens that issuers prefer

VTS (Visa Token Service) and MDES (Mastercard Digital Enablement Service) tokens replace the static PAN. Issuers recognise the token as a higher-trust credential and approval lift follows.

Decline-aware cascade

ISO 8583 decline codes are classified soft vs hard at the platform level. Soft declines from one acquirer cascade to the next ranked lane inside the same authorisation; hard declines (insufficient funds, blocked card) don't cascade and don't waste retries.

Updaters keep issuer credentials fresh

Scheme account updaters surface re-issued, lost-and-stolen or expired-and-renewed cards via the network. Recurring renewals don't fail on card re-issuance the merchant never sees.

How card issuer processor flows look

From card entry to issuer approval in six steps

What happens between the buyer entering their card and the issuer returning an approval — and where topropay sits inside that chain.

  1. 01

    Cardholder enters card

    The buyer enters card credentials (or taps a wallet) on the merchant's hosted checkout, embedded fields or SoftPOS surface. Data goes into the PCI L1 vault before any acquirer sees it.

  2. 02

    Platform looks up the BIN

    The BIN identifies the issuer, scheme, card product (credit / debit / prepaid / commercial) and country. The routing engine scores connected acquirers against this issuer / scheme / country triple.

  3. 03

    Authorisation through the scheme

    The top-ranked acquirer sends the authorisation through the scheme network to the credit card issuer processor. The issuer authorises or declines based on the cardholder's account, risk profile and scheme rules.

  4. 04

    Issuer response & SCA

    If SCA / 3DS is required (PSD2 in Europe), the platform fires EMV 3DS2 selectively per issuer behaviour. Frictionless flows pass through; step-up where the issuer or amount require it.

  5. 05

    Cascade on soft decline

    Soft-decline codes (do-not-honour, issuer-not-available, expired but recoverable) cascade to the next ranked acquirer inside the same authorisation. The buyer sees one decision, not a retry-and-fail-twice loop.

  6. 06

    Settle and reconcile

    Captured authorisations settle through the winning acquirer; settlement files normalise into one ledger tagged by issuer BIN, scheme, acquirer and currency.

Main use cases

Where issuer-aware acquirer-side orchestration earns its keep

Six merchant shapes where reading the issuer side hard and routing the acquirer side smart turns into approval-rate uplift.

  • DTC

    Cross-border DTC with mixed issuer mix

    Buyers across markets carry cards from many issuers. BIN-aware routing picks the regionally-optimal acquirer per issuer / country pair, lifting issuer-side approval rates measurably.

  • SaaS

    SaaS recurring on network tokens

    VTS / MDES tokens issued at first authorisation survive issuer re-issuance via scheme updaters; recurring renewals don't fail when the issuer reissues the underlying card.

  • Travel

    Travel with delayed-capture across issuers

    Auth-only at booking, capture at fulfilment — the credit card issuer processor sees both events tied to the same network token, reducing dispute friction.

  • B2B

    B2B commercial card acceptance

    Commercial BIN ranges read at look-up; Level 2 / Level 3 data sent when the issuer prefers it, lowering interchange on the commercial-card side of B2B receivables.

  • Risk

    High-risk verticals with chargeback-aware routing

    Issuer-side dispute behaviour varies by vertical; routing weights rotate around at-risk acquirer / issuer combinations to protect scheme-programme positions.

  • PSP

    PSPs reselling issuer-aware processing

    Resellers get the same BIN-aware routing engine and per-merchant routing policies for their downstream merchants. The PSP keeps the relationship; the platform handles the issuer-side message exchange.

Platform features

Capabilities behind issuer-side-aware acquirer-side processing

Twelve capabilities the platform reuses across every issuer-side interaction — BIN look-ups, network tokens, decline classification, scheme programmes and one ledger across the panel.

  • BIN look-ups Every card identified by BIN — issuer, scheme, product, country — before routing decision.
  • Per-issuer approval scoring Live approval rates per issuer feed into the routing engine; weights re-rank in near-real-time.
  • Network tokens (VTS / MDES) PAN replaced by issuer-honoured network tokens; refund, recurring and SCR flows use the token.
  • Scheme account updaters Re-issued, expired or lost-and-stolen cards updated via the scheme; recurring billing doesn't fall off.
  • ISO 8583 decline classification Soft vs hard decline codes mapped at the platform level; cascade triggers only on soft.
  • Selective EMV 3DS2 SCA challenges fire per issuer behaviour and per PSD2 exemption logic; frictionless flows pass through.
  • PCI DSS Level 1 vault Card data captures into the platform vault before any acquirer sees it; sub-merchants inherit the posture.
  • Per-BIN routing policies Pin specific BIN ranges to specific acquirers; weight commercial vs consumer BINs differently.
  • Unified dispute queue Chargebacks from issuers via any acquirer land in one queue; evidence-pack templates per vertical.
  • Scheme programme posture Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP positions surfaced per acquirer; routing rotates around at-risk lanes.
  • Webhooks & lifecycle events Signed events for auth, capture, decline, settle, dispute; replay-safe IDs; per-acquirer notifications normalised.
  • One reconciliation feed Settlements, interchange, scheme fees and chargebacks across every connected acquirer in one ledger.

Trust & compliance

Compliance posture for credit card issuer and acquirer interactions

One audited environment for the orchestration layer; scheme-programme positions surfaced per connected acquirer; sub-merchants inherit the posture across every issuer / acquirer / scheme combination.

PCI DSS Level 1
Annual on-site assessment plus quarterly ASV scans; sub-merchants inherit the posture across every connected acquirer.
Scheme programmes
Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP positions surfaced per acquirer; routing weights can rotate around at-risk lanes.
SCA & PSD2
Selective EMV 3DS2 on the authorisation path keeps approval high in Europe without skipping the SCA bar.
Network tokens
VTS and MDES tokens replace the PAN in the vault; refund and recurring run on the token, not the underlying credential.
Sanctions & AML alignment
Sanctions screening at onboarding; AML monitoring tuned per merchant vertical, volume and country mix.
Licensed verticals only
Licensed gaming, regulated financial services and other compliance-bound verticals supported only where current operating licences exist. Grey and black-market verticals are out of scope.

Ready to read the issuer side better

Route acquirer-side authorisations against issuer-side behaviour.

A 30-minute routing review covers the BIN mix in your traffic, per-issuer approval patterns, the connected acquirers that fit, and a sandbox to test against before any commercial commitment.

Book a routing review Read the API docs

Frequently asked

Buyer questions about card issuer processing on topropay

Definitions, the four-party model, where topropay sits, decline-code handling and the practicalities of routing acquirer-side authorisations against issuer behaviour.

  1. 01

    What does card issuer processing actually mean?

    Card issuer processing is the issuer-side half of a card transaction — the bank or non-bank that issued the cardholder's card receives an authorisation request via the scheme network, checks it against the cardholder's account and risk profile, and returns an approval or decline. It sits opposite acquirer-side processing in the four-party model.

  2. 02

    Is topropay a card issuer processor?

    No. topropay is the acquirer-side orchestration layer — the merchant's side of the four-party model. The platform doesn't run a card issuer processor stack; it integrates with the issuer side via the scheme network through licensed connected acquirers.

  3. 03

    How does the platform optimise for credit card issuer processing behaviour?

    Credit card issuer processing behaviour varies per issuer BIN, per scheme, per region and per amount. The routing engine reads BIN on every authorisation, scores connected acquirers against the issuer / scheme / country triple, and picks the highest-EV lane. VTS / MDES network tokens are used by default because issuers honour them with higher approval rates.

  4. 04

    What's the role of the credit card issuer processor in approvals?

    The credit card issuer processor runs the issuer-side authorisation logic — balance check, fraud check, scheme rule enforcement, SCA decisioning. It returns the response code that the acquirer (and topropay) reads. Decline codes classified soft trigger the platform's cascade; hard declines don't.

  5. 05

    Is there a difference between credit card issuer acquirer roles?

    Yes — credit card issuer acquirer describes the two ends of a card transaction. The issuer authorises against the cardholder's account; the acquirer holds the merchant's MID and submits the authorisation. The same scheme network connects them. topropay sits on the acquirer side; the issuer side belongs to the cardholder's bank.

  6. 06

    How do credit card issuer and acquirer interactions look in the topropay flow?

    credit card issuer and acquirer interactions in the topropay flow are: authorisation goes from the buyer to topropay's vault, to the routed acquirer, through the scheme to the issuer, and back. Network tokens (VTS / MDES) carry through the chain so the issuer recognises the credential as scheme-tokenised.

  7. 07

    Does topropay process declines from the issuer side intelligently?

    Yes. ISO 8583 decline codes returned by the issuer are mapped at the platform level: soft declines (do-not-honour, transient issuer issues, expired-but-recoverable) cascade to the next ranked acquirer inside the same authorisation; hard declines (insufficient funds, blocked card, fraud-flagged) don't waste retries.

  8. 08

    How do network tokens interact with credit card issuer processing?

    Network tokens (Visa Token Service for Visa, Mastercard Digital Enablement Service for Mastercard) are issuer-side recognised credentials. When the platform sends an authorisation with a VTS / MDES token, the issuer sees a scheme-tokenised credential which carries a higher trust signal and tends to approve at a higher rate than the raw PAN.

  9. 09

    What happens when the issuer re-issues a card?

    When the issuer re-issues a card (expired, lost-and-stolen, BIN-change), the scheme account updaters surface the new credentials. The platform's recurring billing engine references the network token rather than the raw PAN, so renewals carry forward without the buyer re-entering details. Cards re-issued without an updater entry simply re-tokenise on the next live authorisation.

  10. 10

    Can the merchant see issuer-level analytics?

    Yes. The dashboard breaks down authorisation outcomes by issuer BIN, scheme, country and acquirer. Patterns like 'issuer X declines on acquirer Y' surface so the merchant can override the routing policy to pin issuer X to acquirer Z where approval rates are higher.

  11. 11

    How does 3DS / SCA interact with issuer processing?

    3DS2 challenges are negotiated between the merchant's request, the scheme directory server and the issuer's access control server (ACS). The platform fires 3DS2 selectively based on PSD2 exemption logic and per-issuer behaviour; frictionless flows pass through, step-up challenges fire only where the issuer or amount require it.

  12. 12

    Does topropay support direct issuer connectivity (BIN sponsorship, BaaS)?

    topropay's product focus is acquirer-side orchestration. Direct issuer connectivity (BIN sponsorship, banking-as-a-service issuance) sits with specialised issuer-processor platforms; topropay integrates with them via the scheme network when an issuer-side use case is in scope, but doesn't itself act as the issuer processor.

  13. 13

    How does the platform handle commercial card BINs differently?

    Commercial card BINs (corporate, purchasing, fleet, business) are identified at BIN look-up. The platform sends Level 2 / Level 3 transaction data where the issuer prefers it — line-item detail, tax breakdowns, invoice references — which can lower interchange on the commercial-card side of B2B receivables.

  14. 14

    What's the typical approval lift from BIN-aware routing?

    Approval lift from BIN-aware routing varies by merchant vertical, BIN mix and starting baseline. Merchants moving from a single-acquirer setup to topropay's multi-acquirer panel commonly see meaningful uplifts; the platform's parallel-running mode during migration lets the merchant measure the exact lift per BIN before absorbing the rest of the volume.

  15. 15

    Are issuer-side disputes (chargebacks) easier to manage with this setup?

    Issuer-side disputes — chargebacks initiated through the issuer — land in the platform's unified dispute queue regardless of which acquirer carried the original authorisation. Evidence-pack templates per vertical pre-fill with vault token, authorisation metadata and merchant-supplied evidence; automated representment runs for select scheme reason codes.

Related

Related on the topropay platform