Card Issuing as a Service: UK Provider Selection and Programme Costs

What card issuing as a service includes

Card issuing as a service provides infrastructure and contracted support for businesses offering payment cards. Depending on scope, it can cover virtual card creation, physical card fulfilment, transaction processing, lifecycle management, spending controls and reporting. It is not a standard package: a processing platform and a managed programme can both use the label while leaving very different work with the buyer.

Issuing should be distinguished from payment acceptance. An issuing programme provides cards to its users; acquiring and gateway services help merchants accept those cards. Buying issuing technology therefore does not automatically equip the same business to collect card payments from its own customers.

These roles can overlap. The card-scheme rules distinguish sponsorship and programme arrangements; commercial proposals should name the parties performing them. A single invoice does not necessarily mean a single institution provides every service.

Separate the card-processing layer from the resources behind it. A card API does not automatically include a customer payment account, lending capital or credit underwriting. Physical-card production, delivery, replacement stock, digital-wallet enablement and customer support may also be optional or separately priced. Confirm which capabilities are available to the proposed UK customer population, rather than assuming a provider's global product description establishes programme eligibility.

• Request a component schedule showing included services, partner dependencies and responsibilities retained by your business.
• Identify the authoritative records for card status, available funds, pending authorisations and posted transactions.
• Establish how the platform exposes declines, reversals, refunds and disputes to finance and support teams.
• Confirm whether the supplied tools serve internal administrators, cardholders or both.

For example, a corporate expense proposition needs more than card creation: it must link an approved user to the right funding source, represent purchases accurately and support employees when transactions fail. Defining that complete service boundary makes subsequent provider, responsibility and cost comparisons meaningful.

Set programme requirements and UK compliance responsibilities

Define the card programme before requesting proposals. State whether the product is a commercial expense card, consumer prepaid card, debit card, charge card or credit card; whether cards are physical, virtual or tokenised; and who the cardholders will be. Record the UK legal entity offering the product, target customer types, permitted countries, currencies, expected active cards, transaction count, annual spend, funding method and launch date. Credit and consumer propositions require additional legal analysis, so a debit or prepaid pilot should not be treated as authority to offer credit later.

Translate the proposition into an operating model. A regulated issuer issues the payment instrument and, where applicable, e-money. A BIN sponsor provides access to a card scheme under its principal membership. An issuer processor handles authorisation, clearing and transaction records. A programme manager coordinates onboarding, card operations, fraud, disputes and reporting. One provider may perform several roles, but the contract must identify the legal entity responsible for each role and every material subcontractor.

Map the UK regulatory perimeter to the actual money flow. If stored monetary value is issued on receipt of funds and used for payments, assess whether the arrangement constitutes e-money and which permissions or exemptions apply. Providing payment services in the UK normally requires the relevant authorisation, registration or exemption. Consumer credit, credit broking or lending activity can require separate permissions. Verify the exact issuer, payment institution or e-money institution and its relevant permissions on the Financial Services Register, together with any required payment-services agent registration. An e-money distributor is not registered in the same way as a payment-services agent: verify its appointment with the principal and confirm that applicable notification requirements have been met. A technology supplier's brand name is not evidence that the proposed programme is covered.

Allocate compliance tasks in a signed responsibility matrix. It should cover customer due diligence, business verification, beneficial-owner checks, sanctions screening, transaction monitoring, suspicious-activity escalation, customer risk rating, periodic review, record retention and regulatory reporting. The regulated issuer remains accountable for regulated obligations that it outsources, but the programme operator must still perform its contracted controls correctly and maintain evidence. Confirm whether the business will act as an agent or distributor, document its data-protection roles separately, and obtain legal advice before relying on an exclusion.

Assess whether the Consumer Duty applies to the proposed customers, product and distribution arrangements; a business-facing proposition should not automatically be treated as outside scope. Where it applies, allocate responsibility for defining the target market, assessing fair value, providing understandable communications and effective support, and monitoring customer outcomes, including those of customers in vulnerable circumstances.

Agree responsibility for Strong Customer Authentication where required, including the use and monitoring of applicable exemptions. For online card payments, confirm who provides and operates the issuer-side 3-D Secure service, how authentication challenges reach cardholders, and how failed authentication and customer support are handled. Test these journeys before launch.

Specify how customer funds are protected. UK payment and e-money firms may have safeguarding duties, which are different from deposit protection under the Financial Services Compensation Scheme. Document when funds become relevant funds, which entity safeguards them, how settlement and scheme collateral are funded, how reconciliations operate and what customers are told if the provider fails. For firms within scope, reflect the safeguarding Supplementary Regime effective from 7 May 2026, including applicable internal and external reconciliation requirements, safeguarding audits, resolution packs and monthly FCA safeguarding returns. Assign owners for the records and evidence needed to meet these obligations. Keep operating cash, customer funds, settlement liquidity and any credit capital distinct in the financial model.

Define PCI DSS scope from the data flow. Tokenisation and hosted components can reduce the systems that handle cardholder data, but outsourcing does not remove the need to confirm provider compliance, document shared responsibilities and monitor it. Limit access to primary account numbers, prohibit storage of sensitive authentication data where not permitted, and agree key management, vulnerability management, logging, incident notification and annual evidence.

UK GDPR responsibilities must also be explicit. Identify the controller and processor for onboarding, fraud, support and analytics; establish a lawful basis; minimise data; set retention periods; complete a data protection impact assessment where risk warrants it; and control subprocessors and international transfers. The cardholder terms, privacy information and issuer disclosures should name the correct entities and match the operational journey.

Finish with measurable acceptance criteria: approved use case, signed role matrix, verified permissions and appointments, funded settlement and safeguarding design, approved customer journey, Consumer Duty assessment where applicable, tested authentication and other controls, support and complaint procedures, reconciliation ownership, security evidence and launch limits. These requirements create a common baseline for comparing providers without assuming that every card issuing service includes the same regulated and operational scope.

Compare UK-relevant card issuing providers

Compare providers against the defined programme, not against a generic feature list. The same brand can act as regulated issuer, BIN sponsor, issuer processor, programme manager or technology platform in one configuration and provide a narrower role in another. Ask for the exact contracting and issuing entities, supported cardholder location, card type, scheme, funding model and production status for the proposed UK use case.

Treat this table as a shortlist, not a conclusion. Provider eligibility, product coverage and regulated structure can change by legal entity, risk appetite and customer segment. Confirm all statements in a written solution design and contract, and verify regulated permissions independently. Sandbox access or a marketing page does not prove that a consumer, credit, crypto, travel or high-risk use case will be approved for production.

Score functional fit using end-to-end journeys. Test cardholder and business onboarding, virtual issuance, physical fulfilment, activation, PIN handling, tokenisation, spending controls, real-time authorisation, reversals, refunds, offline transactions, cash withdrawals, disputes, chargebacks, card replacement and closure. Record whether each feature is live in the UK, provided natively, supplied by a third party or requires custom work.

Compare integration depth rather than counting endpoints. Review API versioning, idempotency, webhook signing, event replay, latency, rate limits, sandbox fidelity, test cards, certification, reporting and raw scheme data. Determine whether the provider supports the required ledger or balance model and how transactions reconcile to settlement and the general ledger. A fast card-creation API is not sufficient if funding, clearing and exceptions remain manual.

Assess regulatory and operational scope in the same matrix. Identify who performs KYC or KYB, sanctions screening, transaction monitoring, customer communications, complaints, fraud operations, dispute evidence, safeguarding, regulatory reporting and scheme reporting. Ask for service levels, incident escalation, business-continuity evidence, subcontractors, card-manufacturer locations and the named team that supports a live UK programme.

Review commercial fit without selecting on headline fees alone. Compare setup work, minimum commitments, card and transaction charges, scheme pass-throughs, FX, disputes, optional modules, interchange sharing, reserves, settlement liquidity and price changes. Test costs at launch, base and downside volumes. A provider with more included operations may have a higher platform minimum but a lower total operating cost.

Use a weighted scorecard tied to the business case. Suggested gates are UK eligibility, appropriate regulated coverage, required card type, acceptable safeguarding and funding design, API and control fit, operational ownership, security evidence, credible launch plan and viable total economics. Invite only providers that pass every mandatory gate to a detailed proposal and technical workshop.

Calculate total programme costs

Calculate card programme cost as a full operating model rather than a price per card. Separate one-off implementation expenditure, recurring fixed commitments, activity-based charges, funding requirements and internal operating cost. Request a complete fee schedule from every provider and identify which items are provider margin, scheme pass-through, third-party charge, tax or refundable collateral.

Build the monthly cost formula from measurable units. A practical structure is: fixed platform fees plus billable active cards multiplied by the active-card rate plus cards created multiplied by card and fulfilment cost plus authorisations and cleared transactions multiplied by their respective rates plus transaction value multiplied by any percentage charges plus exception volumes multiplied by their fees. Confirm whether each monthly minimum is an additional fixed charge or a minimum commitment credited against eligible usage. For a credited minimum, use the higher of the minimum and eligible usage charges, then add charges outside that arrangement. Add internal staff, software and assurance costs separately so outsourced and in-house proposals remain comparable.

Model physical-card economics carefully. The quoted production price may exclude design setup, minimum print runs, chip or material options, packaging, warehousing, postage, returned mail, replacements and obsolete stock. For virtual cards, distinguish a one-time creation fee from recurring active-card or token fees. Estimate created, activated, active and replaced cards separately; these populations are rarely equal.

Do not treat interchange as guaranteed gross revenue. Calculate programme interchange revenue from eligible purchase volume and the contractually agreed net interchange yield, or from gross interchange earned multiplied by the programme's revenue-share percentage, less applicable deductions. Product type, merchant category, domestic or cross-border treatment and regulatory rules can change the economics. Where the UK consumer interchange caps apply, they limit interchange to 0.2% for debit cards, including prepaid cards, and 0.3% for credit cards. These caps apply to relevant transactions where the merchant, acquirer and issuer are located in the UK; qualifying commercial-card transactions are excluded from these caps. The hypothetical 0.45% net yield in the commercial-card example below should therefore not be applied to capped consumer transactions.

Exclude cash withdrawals, refunds and other ineligible value from the interchange calculation. Obtain the provider's calculation method and reporting fields so finance can reconcile the amount. Identify which scheme, issuer or provider deductions are already reflected in the net yield and do not also charge them as separate costs in the model.

Budget expected fraud losses and unrecovered disputed amounts separately from fraud-tool subscriptions, manual reviews and dispute-processing fees. Apply the contractual allocation of losses and allow for expected recoveries. Avoid counting the same loss under both fraud and disputes.

Include liquidity and capital even when they are not accounting expenses. A prefunded programme can require cash in settlement or safeguarding accounts before card spend occurs. The issuer or scheme may require a reserve, collateral or guarantee. A charge or credit product additionally needs lending capital, loss provisions, collections and the correct permissions. Model the cash timing, opportunity cost and downside requirement separately from the profit and loss statement.

Run at least three volume cases. The downside case should apply minimum commitments to low activation and spend. The base case should reflect a realistic ramp by month. The scale case should include tiered pricing, support capacity, additional scheme or country work and operational headcount. Stress fraud, dispute, replacement, FX and customer-support rates rather than assuming they remain constant.

Use consistent decision metrics: first-year cash requirement, first-year total cost, steady-state annual cost, cost per active card-month, cost per successful purchase, cost as a percentage of card spend and contribution after net interchange or subscription revenue. Show both programme contribution and fully loaded contribution after internal staff. This prevents a low API fee from hiding the cost of compliance and manual operations.

Finally, reconcile the model to the draft contract. Record every minimum, tier, indexation clause, pass-through, tax treatment, implementation milestone, termination charge and volume assumption. Flag fees that are quoted only after underwriting or scheme approval. The resulting model should make each provider proposal reproducible and ready for the worked example that follows.

Worked example: first-year costs and unit economics

Consider an illustrative UK commercial expense-card programme launching 10,000 physical cards. Assume an average of 7,500 active cards through the year, equal to 90,000 active card-months, 360,000 purchase transactions and GBP 18 million of eligible purchase volume. The figures below are planning assumptions, not market quotations, and exclude VAT, financing cost, fraud losses and general corporate overhead.

The GBP 0.025 exception allowance per purchase represents an assumed exception frequency multiplied by an average handling cost; it is not a fee charged on every purchase. It excludes fraud losses and unrecovered disputed amounts. In a live model, replace both blended activity rates with the provider's billable events, rates and expected exception volumes.

The programme earns a hypothetical net interchange yield of 0.45% of eligible purchase volume. GBP 18 million multiplied by 0.45% produces GBP 81,000. Assume that deductions reflected in this yield do not duplicate the separately budgeted processing and scheme charges. The programme also charges client businesses GBP 1.50 for each active card-month, producing GBP 135,000 from 90,000 active card-months. Total programme revenue is therefore GBP 216,000.

For an illustrative steady-state year, remove the GBP 55,000 implementation cost and replace the initial GBP 40,000 card-production budget with GBP 8,000 for 2,000 cards covering ongoing issuance, replacements and renewals. Holding active card-months, spending and all other costs constant produces an annual cost of GBP 233,000 and contribution of GBP -17,000. The programme remains loss-making and cannot recover its launch investment under these assumptions. Actual card renewal cycles may also produce uneven annual costs.

Calculate spending-led break-even using variable costs. The first-year model contains GBP 257,000 of costs held fixed and GBP 0.175 per purchase in processing and expected exception-handling costs. At an unchanged GBP 50 average purchase value, these variable costs equal 0.35% of spending. Subtracting them from the 0.45% net interchange yield leaves 0.10% of spending to cover the remaining costs. With subscription revenue fixed at GBP 135,000, illustrative first-year break-even therefore requires GBP 122 million of eligible spending: (GBP 257,000 minus GBP 135,000) divided by 0.10%. That is approximately GBP 1,356 per active card-month.

This break-even result assumes unchanged pricing, average purchase value, exception frequency and fixed operating capacity. It is a sensitivity calculation, not a forecast: handling the additional transactions may require more staff or other expenditure. Alternatively, holding the original spending and activity assumptions constant, the subscription would need to rise to approximately GBP 2.66 per active card-month because GBP 239,000 of cost remains after the GBP 81,000 interchange contribution. This calculation assumes the price increase does not reduce activation or retention.

Assess funding separately from expenses. Suppose the business must provide GBP 100,000 of settlement prefunding and GBP 50,000 of restricted collateral from its own resources, in addition to financing the GBP 104,000 first-year deficit. The illustrative funding requirement would be GBP 254,000 before timing differences, contingency and the excluded costs. The prefunding and collateral are cash requirements, not additional expenses, and this calculation assumes neither is already included in the deficit. Customer-funded balances must be modelled separately and must not also be counted as business-funded liquidity.

The actual funding commitment must cover the peak cumulative cash shortfall plus required liquidity and restricted balances. Upfront implementation and card-production payments, delayed revenue receipts and changes in settlement requirements can make this higher than the illustrative GBP 254,000. A reliable model therefore ramps cards, activity, headcount and cash flows by month and applies the provider's exact interchange, eligibility and fee rules.

Before approval, stress the example. If purchase volume falls 25% through fewer transactions at the same average purchase value, net interchange falls by GBP 20,250 while processing and expected exception costs fall by GBP 15,750. With subscription revenue and fixed costs unchanged, first-year contribution worsens by GBP 4,500 to GBP -108,500. If spending falls through smaller purchases instead, transaction-driven costs may not fall. If physical-card cost rises by GBP 1.00, first-year cost increases by GBP 10,000. If active card-months fall but issued cards do not, cost per active card-month rises. Management should set launch gates for activation, spend, fraud, support cost, funding and contribution, and stop or redesign the rollout if the pilot misses them.

Validate the proposal, contract and launch plan

Validate the preferred provider before treating a commercial proposal as a launch commitment. Convert the sales response into a single solution schedule that names the contracting entity, regulated issuer, BIN sponsor, processor, programme manager, card manufacturer and every material subcontractor. State the approved UK use case, card type, customer segment, territories, currencies, scheme, funding model and planned volumes. Any item marked subject to approval should remain an open launch dependency.

Check permissions independently and match them to the exact legal entity in the contract and cardholder disclosures. Confirm who issues the card and, where relevant, e-money; who safeguards funds; whether the business must be registered as a payment-services agent; and whether credit, cash access or overseas distribution changes the perimeter. If the business acts as an e-money distributor, verify its appointment with the principal and confirm that applicable notification requirements have been met, rather than treating distributor status as an agent registration on the Financial Services Register. Require notification and approval controls for any later change of issuer, BIN, scheme, safeguarding bank or regulated subcontractor.

Reconcile the pricing schedule line by line to the financial model. Include implementation milestones, monthly minimums, volume tiers, card stock, shipping, transaction charges, scheme fees, FX, disputes, optional modules, support, reserves and termination assistance. Define which price changes are permitted, how pass-through charges are evidenced and what happens if regulatory or scheme approval is delayed. Avoid a long minimum commitment before the approved use case and production service are proven.

Negotiate operational terms that can be measured. Service levels should cover API availability, authorisation latency, event delivery, incident acknowledgement, card fulfilment, dispute handling and support response. Define severity levels, escalation contacts, service credits and chronic-failure remedies. Allocate liability for unauthorised transactions, data breaches, scheme fines, compliance failures and provider errors; caps and indemnities should reflect the risks each party controls.

Distinguish card-scheme chargeback procedures from applicable statutory refund rights, including rights relating to unauthorised payments. Document which rights apply to the product and customer type, and assign responsibility for receiving claims, investigating them, funding refunds, meeting legal deadlines and communicating decisions. A statutory refund must not depend on successful recovery through a chargeback where the law requires earlier reimbursement. Commercial liability arrangements between the parties must preserve applicable customer rights.

Complete security and data due diligence. Confirm the provider's PCI DSS scope and current validation, but do not treat certification as a substitute for the programme's own responsibility. Approve the data-processing agreement, controller and processor roles, retention, deletion, audit access, subprocessors, international transfers and incident deadlines. Test webhook authentication, access control, key rotation, logging, vulnerability management and disaster recovery.

Run production-like acceptance testing across the entire lifecycle. Cover onboarding approval and rejection, virtual and physical issuance, activation, PIN and wallet flows, controls, authorisation, reversal, refund, clearing, settlement, dispute, card replacement, closure and reconciliation. Test chargeback and statutory refund workflows separately, including applicable deadlines and cases where a refund is due before scheme recovery. Test duplicate requests, delayed and repeated events, provider outages, insufficient funding and manual escalation. Finance must prove that every transaction can be traced from customer instruction to provider report and ledger entry.

Launch through a bounded pilot with named decision owners. Set limits on customers, cards, spend, geography and features. Define go or no-go thresholds for activation, decline rate, fraud, losses, support demand, reconciliation breaks, uptime and unit contribution. Hold daily operational review during the first period and require formal approval before increasing limits or adding a new card type.

Protect the exit route from the start. The contract should provide data export, record retention, cardholder communications, transition support, treatment of funds and disputes, remaining card stock and secure deletion. Confirm whether cards, tokens, BINs or customer consents can migrate or must be reissued. A proposal is launch-ready only when the regulatory model, economics, technology and operating controls are all evidenced and the unresolved conditions have accountable owners and deadlines.