The life of a virtual card, from order to last payment

It is easy to think of a card as a thing that simply exists. A virtual card is better understood as something with a life: it is ordered, checked, issued, used, and eventually it reaches an end. Each stage involves different people and different decisions, and knowing them makes the whole process calmer.

This guide follows one imaginary card, ordered to pay for a year of website hosting, from the first click to its last payment. The details are the ones you will meet in your own space.

Stage 1: the order

The story starts in the card assistant. It asks one question at a time. How much should the card hold? The owner of our example card wants to pay a hosting plan that costs a little under a hundred a year, plus the domain renewal, so they choose a balance that covers both with a small margin.

The assistant then shows the price, worked out on our server: a funding fee of 15% of the balance plus a setup fee of $5.00. That price is held for 30 minutes. Nothing has been charged yet; the assistant only shows what the card will cost.

Next comes the payment method. Our owner pays by crypto transfer: the assistant shows the receiving address, the network and the exact total. They send the transfer from their wallet and paste the transaction ID into the assistant. The order now exists, with its own reference, and it waits for a person.

If you prefer forms to conversations, the simple order form does exactly the same steps on one page. Sizing a card: matching the balance to the job helps with the first question, which is the one people hesitate over most.

Stage 2: the review

Every order is checked by someone on our team before a card is issued. For a transfer, that means finding the transaction on the network, checking that the full amount arrived on the right network, and matching it to the order. For a hosted checkout, the payment provider confirms the payment, and a person still looks at the order before the card is issued.

If something does not match (an amount short, a transfer on the wrong network, a transaction ID already used) the order is held and the customer gets a clear note about what is missing. Why a person checks every card order here explains why this step is done by people rather than by a script.

Our example payment is fine, so the order moves on.

Stage 3: the issue

The card is issued into the space. A signal appears in the corner of the screen and an email arrives. In the Cards app, the new card sits in the carousel, its number masked: four groups, only the last four digits visible.

The full details stay sealed. To see them, the owner enters a fresh code from their authenticator app; the card turns over, shows the number, expiry date and security code, and seals itself again after a short time. Nothing about the card is left on screen for longer than it needs to be. Sixteen digits, a date and a short code: anatomy of a card explains what each of those details does.

Stage 4: working life

Our owner unseals the card, goes to the hosting provider's billing page, and adds it as the payment method. The hosting company charges the yearly plan. A few weeks later, the domain registrar charges the renewal. The card's balance goes down by each amount.

A few things happen during a card's working life that are worth knowing:

• Holds. Some services reserve an amount before charging the final one. The hold lowers the available balance until it settles or gets released. Holds, authorisations and the amount that settles explains this.
• Declines. If a payment would exceed the balance, the card declines it. That is the card doing its job as a ceiling.
• Status changes. If something unusual happens, our team may freeze a card while looking into it. A frozen card is paused, not ended. A card's status label, and what it changes covers what each state means.

Because this card has one job, its history is short and readable: two charges, both expected. If a third charge appeared from a shop the owner does not recognise, it would stand out at once.

Stage 5: the end

A year later, the hosting is moved to another provider. The card has a small balance left and nothing else to pay. Our owner has three choices:

• Leave it. The balance stays on the card and can still be used for something else before the expiry date.
• Ask for a refund, where the refund rules allow it. Our example card has been used, so a refund is possible only if at least a set amount remains; a small leftover balance is not refundable. An unused card could have its full balance refunded. The refund rules give the exact conditions.
• Have it closed. Closing is final; the card can no longer be used.

One practical point: refunds from shops travel back to the card that paid. If you expect a refund from a shop (for a cancelled plan, for example), keep the card open until it arrives.

What the story shows

Following one card makes a few things clear:

• Decisions happen at the start. The balance you choose and the job you give the card shape everything after.
• People are involved where it matters. A person checks the payment before any card is issued.
• The details are protected by default. Sealed until you need them, sealed again soon after.
• The end is a choice. A card can rest, be refunded where allowed, or be closed.

A note on many cards

Our example had one card with one job. Most people end up with a few: one for hosting, one for software, one for a trip. The same life story applies to each, just running at different speeds. One card, one purpose: splitting spending across cards explains how to plan a small set of cards so that each one's story stays simple.

If you have not ordered a card yet, the tour shows each stage in the space, and the questions page answers the practical details.