> For the complete documentation index, see [llms.txt](https://docs.payments.thalescloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.payments.thalescloud.io/classic-tokenization/use-cases/card-enrolment/generic-enrollment-flow/step-1-capture-card-details.md).

# Step 1 – capture card details

First, the end user provides the card details used for Tokenization.

Capture these details using one of these methods:

* Manual entry in the issuer application or digital wallet application
* Optical character recognition (OCR) from a picture of the physical card
* Card details imported from an existing Card-on-file (COF) record

A common approach is to start in the issuer application. This enrollment flow is often called **push provisioning** or **in-app provisioning**.

{% hint style="info" %}
If TSH is configured to support a domestic scheme, check the details [domestic scheme treatment](/classic-tokenization/use-cases/card-enrolment/generic-enrollment-flow/step-1-capture-card-details/domestic-scheme-treatment.md).
{% endhint %}

### Push provisioning from the issuer application

The diagram below shows the overall push provisioning flow for card details capture.

<figure><img src="/files/QoqPyXfjy0VeK1NFjcSw" alt=""><figcaption><p>Push provisioning flow to capture card details.</p></figcaption></figure>

In a push provisioning scenario, the Tokenization flow follows the standard “green flow”. It adds an initial step where the issuer application provides two elements to the token requestor (wallet provider), via an SDK or a mobile operating system API:

1. **Encrypted card information**\
   The issuer application sends encrypted card data (typically the PAN and expiry date).
2. **Authentication proof**\
   The issuer application sends an authentication proof for the token requestor or the payment network. This demonstrates that the issuer strongly authenticated the end user.

#### Encryption and authentication proof

* **Encryption algorithm**\
  The encryption algorithm is specific to each token requestor. The corresponding specification is provided by the token requestor.
* **Authentication proof algorithm**\
  The authentication proof format and algorithm are specific to each payment network (for example, VTS or MDES). The relevant specifications are provided by the payment network.

#### CVV2 handling in app-to-app flows

In app-to-app push provisioning flows (step 4 in the diagram), the issuer backend never receives the CVV2. The token requestor collects and handles the CVV2 according to payment network requirements.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.payments.thalescloud.io/classic-tokenization/use-cases/card-enrolment/generic-enrollment-flow/step-1-capture-card-details.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.