To issue virtual cards, you need a sponsor bank that holds network membership with Visa or Mastercard, a compliance program covering Regulation E and anti-money laundering identity verification, state money transmitter licenses where required, and an issuing platform that can generate card credentials through an API. The technical part takes under a second. Everything that makes it legal takes months.
Why You Need a Sponsor Bank
Only a chartered, federally insured bank can issue payment cards on the Visa or Mastercard networks. If you’re a fintech, an expense-management platform, or any other non-bank entity, you need a sponsor bank: a chartered institution that holds network membership and provides you with a Bank Identification Number, which forms the first six to eight digits of every card number. The sponsor bank’s charter is what gives your cards legal standing to move money through the payment system.
This partnership carries real weight on both sides. Federal banking agencies require every insured depository institution to meet operational and managerial standards covering internal controls, information systems, loan documentation, credit underwriting, and asset quality.1Office of the Law Revision Counsel. 12 USC 1831p-1 – Standards for Safety and Soundness Those obligations flow down to the card programs the bank sponsors. If unauthorized charges post, funds go missing, or a compliance failure surfaces, the sponsor bank is on the hook alongside you. Expect them to audit your program accordingly.
Federal Compliance You Have to Build Around
Regulation E
Virtual card transactions are electronic fund transfers, which puts them under the Electronic Fund Transfer Act and Regulation E at 12 CFR Part 1005.2eCFR. 12 CFR Part 1005 – Electronic Fund Transfers (Regulation E) As an issuer you have to disclose fees and limits, provide error resolution procedures, and cap consumer liability for unauthorized transfers. Reporting windows and dispute workflows need to be part of the platform from day one, because Regulation E carries civil liability for financial institutions that fall short.3eCFR. 12 CFR 1005.6 – Liability of Consumer for Unauthorized Transfers
Customer Identification and AML
Before you generate a single card, federal anti-money laundering rules require you to verify who you’re issuing it to. The Bank Secrecy Act’s Customer Identification Program rule at 31 CFR 1020.220 sets the floor. At minimum, you need the customer’s legal name, date of birth for individuals, a street address, and a taxpayer identification number: a Social Security Number for U.S. persons or an Employer Identification Number for businesses.4eCFR. 31 CFR 1020.220 – Customer Identification Program Requirements for Banks The address has to be a residential or business street address; a PO box alone will not clear the rule except in narrow cases. Those data points feed into verification systems that cross-reference government databases and credit bureaus to confirm the identity is real.
State Money Transmitter Licensing
This is where new issuers stumble. Issuing stored value, which is what a funded virtual card represents, qualifies as money transmission in most states. The Conference of State Bank Supervisors’ model act defines money transmission to include “selling or issuing stored value,” and the majority of states have adopted some version of that framework. A non-bank issuer operating without a money transmitter license in a state that requires one is breaking that state’s law, no matter how clean the federal picture looks.
Costs and requirements vary sharply. Application fees alone range from under $200 to $5,000, and most states also require surety bonds, audited financial statements, and background checks on controlling persons. Chartered banks and their direct agents are generally exempt, which is another reason the sponsor bank structure matters: depending on how the partnership is drafted, the bank’s charter can shelter your program from needing individual state licenses.
Single-Use or Multi-Use Cards
Decide which card type fits each use case before you build the issuance workflow, because the choice shapes fraud exposure and reconciliation.
A single-use virtual card is generated for one specific transaction and closes automatically. The card number, amount, and often the merchant are locked at creation. Once the payment clears, the credential dies. That makes single-use cards a natural fit for approved invoices, one-time vendor engagements, and any payment where you know the amount up front. Post-transaction fraud exposure is essentially zero.
A multi-use virtual card stays active across multiple payments, typically to the same vendor or within the same category. Monthly software subscriptions, recurring vendor invoices, and project-level budgets sit here. You set a spending cap and let the card handle ongoing charges without generating a new number each time. The tradeoff is that a live card number in a vendor’s system carries more fraud risk than one that self-destructs after a single charge.
Most platforms issue both through the same API, with the card’s behavior controlled by parameters set at creation.
How a Card Actually Gets Created
Once the banking partnership, compliance framework, and identity verification are in place, generating a card is the easy part. A developer sends a POST request to the issuing platform’s card endpoint with parameters for the cardholder ID, spending limits, merchant restrictions, and whether the card is single-use or multi-use. The system validates the request against the verified customer profile, generates the credentials, and returns them, typically in under a second. Teams using a dashboard rather than code get the same thing behind a “Create Card” button, since the dashboard is a visual wrapper on the same API. Card number, expiration date, and security code are delivered through an encrypted channel to the cardholder’s secure interface or digital wallet.
Just-in-Time Funding
Many modern platforms don’t require you to pre-load funds. Instead, money moves from your funding source into the card account at the moment a transaction is authorized. A merchant submits an authorization request to the card network, the network routes it to the issuing platform, the platform validates the transaction against your spend controls, and if everything checks out, funds are pulled from your source account to cover the charge. The authorization response goes back to the merchant and the cycle completes in milliseconds.
Card Profile Controls
Every virtual card carries programmable restrictions set at creation and modifiable through the API.
- Spending limits per transaction, per day, or per month, including single-use cards locked to an exact invoice total.
- Merchant category codes that block entire categories such as gambling or entertainment, or whitelist categories such as office supplies or travel.
- Expiration dates keyed to a fixed date or to a period of inactivity; single-use cards often auto-expire within days.
- Geographic restrictions limiting card use to specific countries or regions.
Charges that fall outside the card’s profile are declined automatically. For businesses managing dozens or hundreds of cards, that replaces after-the-fact expense report review with real-time enforcement.
Rules If You Issue Prepaid or Gift Cards
Virtual cards distributed as general-use prepaid cards or gift cards pick up additional rules under Regulation E’s gift card provisions. The underlying funds must remain valid for at least five years from the date of issuance or last reload. You cannot charge dormancy, inactivity, or service fees until at least 12 months of inactivity have passed, and even then you’re limited to one such fee per calendar month. The fee amount, frequency, and the fact that it’s triggered by inactivity must all be clearly disclosed on the card itself.5Consumer Financial Protection Bureau. 12 CFR 1005.20 – Requirements for Gift Cards and Gift Certificates If the card expires before the funds do, you have to provide a toll-free number and website where the consumer can get a replacement at no charge.
These rules do not apply to closed-loop cards redeemable only at a single merchant, and they do not apply to cards distributed through loyalty or promotional programs. If your virtual card functions as a general-purpose spending tool, they do.
Ongoing Obligations After the Card Is Live
Unclaimed Funds and Escheatment
Virtual card balances that go unused don’t sit on your books forever. Every state has unclaimed property laws that eventually require you to remit dormant funds to the state treasury. Dormancy periods vary: some states trigger escheatment after three years of inactivity, others wait five, and a handful exempt gift cards entirely. If you issue to holders in multiple states, you’re dealing with multiple reporting calendars, thresholds, and exemptions at once. You’ll need systems that track card-level activity, flag accounts approaching dormancy, attempt to contact cardholders before the deadline, and remit funds and file reports with each applicable state.
Form 1099-K Reporting
If you operate as a third-party settlement organization processing card payments, you may have Form 1099-K reporting obligations. For 2026, a 1099-K is required only when the gross amount of reportable payment transactions to a payee exceeds $20,000 and the number of transactions exceeds 200. That threshold was retroactively reinstated to its pre-2021 level under recent legislation.6Internal Revenue Service. IRS Issues FAQs on Form 1099-K Threshold Under the One, Big, Beautiful Bill Whether the obligation lands on you or your sponsor bank depends on which entity actually processes and settles the transactions.
PCI DSS
Every entity that stores, processes, or transmits cardholder data must comply with the Payment Card Industry Data Security Standard. Visa’s rules make this explicit: issuers and acquirers are responsible for ensuring PCI DSS compliance across their service providers and merchants, and compliance must be validated at least every 12 months.7Visa. Account Information Security (AIS) Program and PCI Most non-bank issuers reduce their compliance scope by using tokenization and avoiding raw card data storage. The issuing platform generates and encrypts card credentials, delivers them to the cardholder through a secure channel, and your systems only handle tokens that reference the card without exposing the actual numbers. That doesn’t eliminate your PCI obligations, but it shrinks the surface area you have to secure and audit.