Card Data Capture and Secure Tokenization

Dinape is designed to reduce the handling of clear text card data wherever possible.

For most merchant-facing card integrations, card details are captured through a secure iframe provided by Dinape. The iframe collects the card information from the customer and converts it into a token before the data reaches the merchant system or the wider Dinape payment platform.

For server-to-server integrations where a merchant sends clear PAN data directly, Dinape uses a tokenization proxy. The proxy receives the card data in a controlled environment, converts it into a token, and forwards only tokenized payment data into the wider platform.

Why tokenization is used

Tokenization is used as a security mechanism to protect sensitive card information.

The main purpose is to make sure that clear text card data is avoided entirely where possible, or converted into a token as early as possible in the payment flow.

Merchants do not need to manage tokenization manually in standard iframe-based integrations. For server-to-server integrations, tokenization is handled by the tokenization proxy before payment data continues through the platform.

Supported card data capture flows

Dinape supports two card data capture flows, depending on the merchant integration model.

Secure iframe flow

The recommended approach is to use the secure iframe.

In this flow, card details are entered inside the iframe and are not collected through merchant-controlled form fields.

A typical secure iframe flow includes these steps:

1. The merchant application displays the secure card capture iframe.
2. The customer enters their card details inside the iframe.
3. The iframe securely captures the card information.
4. The card data is tokenized before it reaches the merchant application or the wider Dinape platform.
5. The merchant receives a token or payment reference that can be used to continue the transaction.
6. The payment is processed without exposing clear text card data to the merchant.

INFO

For iframe-based integrations, merchants must not collect card numbers, expiry dates, or card security codes in their own forms. These fields must be entered only inside the secure iframe.

Server-to-server flow with tokenization proxy

For server-to-server integrations, a merchant may send clear PAN data directly to the Dinape endpoint designed for this purpose.

In this flow, card data is sent to the tokenization proxy before it reaches the wider payment platform.

A typical server-to-server flow includes these steps:

1. The merchant system sends the card data to the tokenization proxy.
2. The proxy receives the clear PAN data in a controlled environment.
3. The proxy converts the PAN into a token.
4. Only tokenized payment data is passed into the wider Dinape platform.
5. The payment continues using the token rather than the clear PAN.

This flow is intended for integrations where the merchant has the required setup and compliance scope to collect and transmit clear PAN data server to server.

WARNING

Server-to-server card data transmission should only be used by merchants that are allowed to collect and transmit clear PAN data. Card data must be sent only to the designated tokenization proxy endpoint.

Merchant responsibilities

Merchant responsibilities depend on the integration model.

For iframe-based integrations:

• Do not collect card numbers in merchant-controlled forms.
• Do not collect expiry dates in merchant-controlled forms.
• Do not collect card security codes in merchant-controlled forms.
• Use the secure iframe for card data entry.

For server-to-server integrations:

• Ensure your systems are allowed to collect and transmit clear PAN data.
• Send card data only to the designated tokenization proxy endpoint.
• Do not send clear PAN data to general payment processing endpoints.
• Ensure your integration follows the required security and compliance requirements.

Benefits

This approach helps:

• reduce exposure to sensitive card data
• keep clear text card data out of the wider payment platform
• support secure iframe-based integrations
• support server-to-server integrations through a controlled tokenization proxy
• simplify payment processing after tokenization
• reduce the risk of accidental card data handling

Important note

Tokenization is not a feature that merchants need to manage manually. It is part of the secure payment infrastructure used by DINAPE to protect cardholder data.

For most merchants, the relevant integration point is the secure iframe. For server-to-server merchants, the relevant integration point is the tokenization proxy endpoint.

Next steps

Review checkout integration

Use the checkout guides to understand how DINAPE payment flows are created and processed.

Continue to Payment API

Add authentication to card payments

Use 3D Secure to understand how cardholder authentication can be applied to supported card payments.

Continue to 3D Secure