# Dispatching cards

> The two ways an eMSP puts charge cards in drivers' hands, physical branded cards and virtual cards.

An eMSP has two ways to give a driver a card:

1. a physical, branded card, or
2. a virtual card, which also covers turning an RFID card the driver already holds into a means of payment.

## Virtual cards

A virtual card is a token with no physical card. The platform creates the token, which can carry the UID of an RFID card the driver already has, and makes it available over the roaming network, so that existing card can pay for charging across the connected networks. A virtual card is usable at once, with nothing to post or activate.

A typical flow over the API:

- create the accounts and users ([POST /1/users](/docs/platform/reference/platform-api/users#postv1users), [POST /1/accounts](/docs/platform/reference/platform-api/accounts#postv1accounts)),
- create the virtual cards ([POST /1/cards/virtual](/docs/platform/reference/platform-api/cards#postv1cardsvirtual)),
- list an account's cards ([POST /1/cards/search/fast](/docs/platform/reference/platform-api/cards#postv1cardssearchfast)),
- block and unblock a card ([POST /1/cards/:card/disable](/docs/platform/reference/platform-api/cards#postv1cardsbycarddisable) and [POST /1/cards/:card/enable](/docs/platform/reference/platform-api/cards#postv1cardsbycardenable)),
- pull the driver's charge sessions ([POST /1/sessions/search](/docs/platform/reference/platform-api/msp-sessions#postv1sessionssearch)).

## Physical cards

Road can supply a fully white-labelled physical card, and run the volume creation, activation and posting on your behalf. Speak to your account manager to set this up.

A physical card moves through a short lifecycle:

1. **Ordered** for a driver, and paid for where it is a self-service order.
2. **Assigned a token.** Cards are held pre-encoded with an RFID UID; the platform takes one from stock, binds it to the driver's account, and mints its contract ID.
3. **Sent** to the driver.
4. **Activated**, and ready to charge.