Dimension One: Is the Card Present?
The most basic classification is whether the card itself is present when the transaction happens:
| CP: Card present | CNP: Card not present | |
|---|---|---|
| How it happens | Inserting, tapping, or swiping the card | Entering card details online, phone orders, mail orders |
| What can be verified | Chip or magnetic-stripe data, PIN or signature | Only the entered details: card number, expiry date, security code |
| Fraud risk | Relatively low | Higher: no physical card is required |
| Who bears fraud losses | Usually not the merchant | Usually the merchant, unless strong authentication was used |
The right-hand column is the defining feature of online payments: no physical card is involved.
Because merchants in CNP transactions can't get the card itself, the industry introduced mechanisms like strong customer authentication (3DS being one of them) to fill in the missing “the cardholder really is the one acting” step. How 3DS actually behaves with virtual cards is covered separately on the 3DS page.
Dimension Two: Who Initiates the Transaction
The second dimension has nothing to do with the card: it's about how the transaction gets triggered:
| CIT: Cardholder-initiated | MIT: Merchant-initiated | |
|---|---|---|
| How it's triggered | The customer clicks pay in the moment | The merchant initiates it in the background per the agreement |
| Typical scenarios | One-time purchases, first subscription payment | Subscription renewals, auto-renewals, catch-up charges |
| Does the customer need to be present? | Yes | No |
| What it relies on | Card details entered or saved at that moment | The payment credential saved during the first transaction |
Subscription scenarios are a combination of both types, not just one of them.
The key point: an MIT requires a prior CIT. When the customer first binds the card and pays, a CIT completes, and only then does the merchant hold the credential to initiate future MITs. So “first payment succeeds, second fails” is usually not a charging problem: that particular MIT wasn't accepted by the issuing side. Two causes are common: the transaction type isn't allowed, or the balance can't cover that period.
The Combinations Behind Four Common Scenarios
Stack the two dimensions together and it's clear where everyday scenarios land:
| Scenario | Card present? | Who initiates | What to watch out for |
|---|---|---|---|
| In-store card payment | CP | CIT | Requires a physical card: virtual cards can't do this |
| One-time e-commerce purchase | CNP | CIT | May trigger 3DS verification |
| First subscription payment | CNP | CIT | This step creates the credential for later MITs |
| Subscription renewal | CNP | MIT | Type and balance: missing either one means failure |
The two subscription rows must be read together: without the first row succeeding, there is no second row.
Advertising accounts (such as Facebook Ads and Google Ads) work differently: instead of fixed-cycle billing, they use auto top-ups triggered by thresholds or periods, which puts them in the merchant-initiated category as well. That's why ad accounts have different requirements for cards than one-time shopping does: the card must allow the merchant to charge it without anyone actively involved.
How a Type Mismatch Shows Up as a Failure
A transaction type mismatch doesn't throw a prominent error: it usually looks like this:
- The first payment goes through fine, and the page says the card is bound successfully;
- At the second payment or some trigger point, the charge fails, and no on-screen action can reproduce it;
- Paying manually again usually works: because that's a CIT again;
- The next cycle fails the same way.
The pattern of “works manually, fails automatically” is the most reliable signal of a type problem. It differs from insufficient balance: where a manual attempt fails too: and from a restricted card: where a manual attempt also won't pass.
Where 3DS Fits in This Chain
3DS (Three-Domain Secure) plays the role of “restoring the cardholder's presence” within transaction types, and it mainly appears in the CNP + CIT combination:
- It happens at the first CIT, when the customer is asked to complete an additional verification;
- After verification succeeds, liability for the transaction may shift from the merchant to the issuer;
- Subsequent MITs usually skip per-transaction verification and rely on the credential established the first time;
- If the card doesn't support it or the merchant hasn't enabled it, the transaction may fail outright at the verification step.
So 3DS complements transaction types rather than replacing them. How this platform's cards perform with 3DS, and how it's handled, is covered on the 3DS page.
Get the Type Right and the Card Is Properly Set Up
Now that the concepts are clear, let's get to card setup and troubleshooting. Following this order resolves the most common “first payment succeeds, renewal fails” pattern before it happens:
- First, find out whether the transaction is a CIT or an MIT: one-time purchases only need the former; subscriptions and ad accounts need both. Ask the merchant, or check whether it will charge the card automatically later.
- Confirm the card allows MIT as a type: that's a setting on the issuing side. It's a common restriction on prepaid cards, so ask clearly when you get the card.
- Keep enough balance for the recurring amount: see the Pricing page for fee terms. An MIT fails outright when the balance is too low at the time it runs: a prepaid card has no credit fallback, so top up to cover the full cycle amount.
- When it fails, first tell whether it's a type or a balance issue: works manually but fails automatically means a type problem; fails manually too means balance or restrictions. The two have completely different fixes.
Cards on this platform are valid long-term, so they work for merchant-initiated recurring billing; BINs in the US, Hong Kong (China), and elsewhere are available. Let's be clear about the boundary: whether a merchant uses MIT, and how it sets its no-password thresholds and cycles, is the merchant's own decision: we can't change it. Whether a transaction is ultimately accepted is also up to the merchant and its acquirer; we don't guarantee approval rates. What's on the card side: the details, type permissions, and balance: is in your control.
For subscriptions and other scenarios that need MIT auto-billing, confirm the card supports recurring billing before choosing: compare card types, then get a card.
FAQ
What's the difference between CP and CNP?
CP means the card is present (insert, tap, or swipe); CNP means it isn't (online, phone, or mail orders). CNP carries higher fraud risk, with liability mostly on the merchant side.
What do CIT and MIT mean?
A CIT is a transaction the cardholder initiates on the spot; an MIT is one the merchant initiates in the background per the agreement. A subscription is a first CIT plus an MIT for each period after.
Why did the first subscription payment succeed but the second fail?
Common causes: the issuing side doesn't allow that MIT (transaction type not supported), or the balance can't cover that period. The telltale sign: manual payments pass while automatic ones fail.
If a manual retry works, does that mean the card is fine?
It means the card itself works, but not necessarily that the type is supported. A manual payment is a CIT; the automatic one is an MIT: different types. Working manually but failing automatically is precisely the signature of a type problem.
How do 3DS and transaction types relate?
3DS is a verification mechanism that restores “the cardholder being present” in CNP scenarios, mainly at the first CIT. It complements transaction types; it doesn't replace them.
What transaction type do ad accounts use?
They auto-top-up by threshold or period, putting them in the merchant-initiated class (the MIT family). That's why they require a card that allows the merchant to charge without anyone acting.
Can a virtual card without a physical form be used in stores?
Not by inserting or swiping directly. Once added to a mobile wallet, it can be used at terminals that accept contactless payments: but that's the wallet standing in for the card; the card itself can't go into a POS terminal.
Can switching cards fix a type problem?
Only if your current card explicitly doesn't support MIT. In most cases the problem is insufficient balance or a permission that wasn't enabled: a new card won't fix a configuration issue.
How can I tell in advance whether a merchant will charge automatically?
Check whether it asks to save your card details for future charges. Anywhere that asks to “save this card” will almost certainly run merchant-initiated billing later: confirm the card allows that type.
Got the idea in a few minutes? Go open a card
Cards start at $1, no monthly fee; account top-up is $0 with a $20 minimum per deposit. See the pricing page for full details.