Tokenization
With our security model, all PCI-sensitive information is transmitted directly between Weavr and the customer-your app handles only non-sensitive tokens.
Your customers' card information is highly sensitive. If you have any type of direct access to this information, you are legally bound to be compliant with the PCI DSS standard. However, you can use our security model to issue and manage cards for your customers without having access to any PCI-sensitive details.
Payment Card Industry Data Security Standards (PCI DSS) is a set of policies and procedures developed to protect card transactions and prevent misuse of cardholders’ personal information. Anyone involved with the processing, handling, transmission, or storage of card data must comply with PCI DSS.
The following card information falls under the PCI-sensitive category:
- End-user password to access card detail information
- The full 16-digit card number
- The 3-digit card verification number (CVVCVV Card Verification Value - the 3-digit security code printed on a payment card, used to authenticate card-not-present transactions. Weavr returns CVV in tokenized form on `GET /managed_cards/{id}` (with a stepped-up token); the value is only detokenized inside the SDK's secure CVV display component.) required to make online purchases
- The card PINPIN Personal Identification Number - the numeric code a cardholder enters to authorize chip-and-PIN purchases and ATM withdrawals. PIN is only present on physical managed cards. Weavr returns it tokenized on `GET /managed_cards/{id}` (with a stepped-up token), and the SDK detokenizes it inside a secure PIN display component. in case of physical cards
With our security model, you can include financial capabilities in your app and qualify for the lowest level of PCI compliance. To ensure the simplest possible PCI compliance procedure you should:
- Use our security model to deliver card details to your customers
- Ensure that your app is running on HTTPS
- Fill in and submit our pre-filled PCI SAQ form
If your company and app are already PCI DSS certified, you can opt out of using our security model. Not having to store PCI-sensitive data is still a benefit but it is not a requirement.
Using the security model
Our security model tokenizesTokenize Replace a card's primary account number (PAN) with a unique digital token that stands in for the real card during a transaction. When a cardholder adds a card to Apple Pay or Google Pay via push provisioning, the wallet provider stores a device-specific token rather than the underlying PAN, so the real card number isn't exposed on the device or shared with merchants. information so that you can transmit it securely. For this to work, you need to integrate your app with our security model both on the client-side and on the server-side:
-
On the client-side, you need to use our UI library to embed secure components for capturing and viewing information.
infoSee the Web SDK documentation for more information on our UI components.
-
On the server-side, you need to send and receive tokens instead of plain text data. In the case of server-side integration, you can use the same APIs independent of whether you use the security model or not. However, if you use the security model, we expect and return tokenizedTokenize Replace a card's primary account number (PAN) with a unique digital token that stands in for the real card during a transaction. When a cardholder adds a card to Apple Pay or Google Pay via push provisioning, the wallet provider stores a device-specific token rather than the underlying PAN, so the real card number isn't exposed on the device or shared with merchants. information for sensitive fields.
Where tokens come from
A token is a short-lived reference to a piece of sensitive data. You never see the underlying value - your backend receives the token, hands it to the SDK in your client app, and the SDK detokenizesTokenize Replace a card's primary account number (PAN) with a unique digital token that stands in for the real card during a transaction. When a cardholder adds a card to Apple Pay or Google Pay via push provisioning, the wallet provider stores a device-specific token rather than the underlying PAN, so the real card number isn't exposed on the device or shared with merchants. it inside a sandboxed component (an iframe on the web, a secure native view on iOS, Android, and React Native).
The four token types map to specific API endpoints and response fields:
| Token | How you obtain it | Response field on the resource | Where the SDK uses it |
|---|---|---|---|
| Card number (PANPAN Primary Account Number - the long card number (typically 16 digits) printed or embossed on a payment card and used to identify the card on the payment network. Weavr never returns the raw PAN to your client; `GET /managed_cards/{id}` returns the PAN in tokenized form as `cardNumber`, and the value is only detokenized inside a Secure UI card-number component (a sandboxed iframe on the web, a secure native view on mobile).) | Server-side: GET /managed_cards/{id} after the user authentication token is stepped-up. | cardNumber (tokenizedTokenize Replace a card's primary account number (PAN) with a unique digital token that stands in for the real card during a transaction. When a cardholder adds a card to Apple Pay or Google Pay via push provisioning, the wallet provider stores a device-specific token rather than the underlying PAN, so the real card number isn't exposed on the device or shared with merchants. form of the PANPAN Primary Account Number - the long card number (typically 16 digits) printed or embossed on a payment card and used to identify the card on the payment network. Weavr never returns the raw PAN to your client; `GET /managed_cards/{id}` returns the PAN in tokenized form as `cardNumber`, and the value is only detokenized inside a Secure UI card-number component (a sandboxed iframe on the web, a secure native view on mobile).) | Card number display component - see web, iOS, Android, React Native. |
| CVVCVV Card Verification Value - the 3-digit security code printed on a payment card, used to authenticate card-not-present transactions. Weavr returns CVV in tokenized form on `GET /managed_cards/{id}` (with a stepped-up token); the value is only detokenized inside the SDK's secure CVV display component. | Server-side: GET /managed_cards/{id}, with a stepped-up tokenStepped-up token An access token that has been elevated to a higher authentication level by successfully completing a step-up challenge (typically an OTP via SMS or a biometric prompt). A stepped-up token is required to perform sensitive operations such as creating a user, managing authentication factors, or confirming high-value transactions. See the [step-up authentication guide](/apis/authentication/stepup/) for how to issue and complete a challenge.. | cvv (tokenizedTokenize Replace a card's primary account number (PAN) with a unique digital token that stands in for the real card during a transaction. When a cardholder adds a card to Apple Pay or Google Pay via push provisioning, the wallet provider stores a device-specific token rather than the underlying PAN, so the real card number isn't exposed on the device or shared with merchants.) | CVVCVV Card Verification Value - the 3-digit security code printed on a payment card, used to authenticate card-not-present transactions. Weavr returns CVV in tokenized form on `GET /managed_cards/{id}` (with a stepped-up token); the value is only detokenized inside the SDK's secure CVV display component. display component on each SDK. |
| Card PINPIN Personal Identification Number - the numeric code a cardholder enters to authorize chip-and-PIN purchases and ATM withdrawals. PIN is only present on physical managed cards. Weavr returns it tokenized on `GET /managed_cards/{id}` (with a stepped-up token), and the SDK detokenizes it inside a secure PIN display component. | Server-side: GET /managed_cards/{id}, with a stepped-up tokenStepped-up token An access token that has been elevated to a higher authentication level by successfully completing a step-up challenge (typically an OTP via SMS or a biometric prompt). A stepped-up token is required to perform sensitive operations such as creating a user, managing authentication factors, or confirming high-value transactions. See the [step-up authentication guide](/apis/authentication/stepup/) for how to issue and complete a challenge.. The PINPIN Personal Identification Number - the numeric code a cardholder enters to authorize chip-and-PIN purchases and ATM withdrawals. PIN is only present on physical managed cards. Weavr returns it tokenized on `GET /managed_cards/{id}` (with a stepped-up token), and the SDK detokenizes it inside a secure PIN display component. is only present on physical cardsPhysical Card A payment card that is printed or embedded in wearables and sent to customers directly. Physical cards are created by first creating a virtual card and then upgrading it to a physical card. They are sent in an inactive state and must be activated by the card assignee before first use.. | pin (tokenizedTokenize Replace a card's primary account number (PAN) with a unique digital token that stands in for the real card during a transaction. When a cardholder adds a card to Apple Pay or Google Pay via push provisioning, the wallet provider stores a device-specific token rather than the underlying PAN, so the real card number isn't exposed on the device or shared with merchants.) | Show Card PINPIN Personal Identification Number - the numeric code a cardholder enters to authorize chip-and-PIN purchases and ATM withdrawals. PIN is only present on physical managed cards. Weavr returns it tokenized on `GET /managed_cards/{id}` (with a stepped-up token), and the SDK detokenizes it inside a secure PIN display component. display component on each SDK. |
| Login credential | Client-side: the user types their password or passcode into the secure input. The SDK calls our tokenizationTokenize Replace a card's primary account number (PAN) with a unique digital token that stands in for the real card during a transaction. When a cardholder adds a card to Apple Pay or Google Pay via push provisioning, the wallet provider stores a device-specific token rather than the underlying PAN, so the real card number isn't exposed on the device or shared with merchants. service and returns a one-time-use token. | Returned in the SDK callback (tokens map). | Login components on each SDK; you exchange the token for a session token via POST /login_with_password or POST /login_with_passcode from your backend. |
For card tokens, retrieve the managed cardManaged Card A payment card (virtual or physical) that can be created and managed through the Weavr platform. Cards can operate in prepaid mode (with their own balance) or debit mode (linked to a managed account). All cards must be assigned to a card assignee who is an Authorised User. on your backend (so the API key never leaves the server), then pass the relevant tokenizedTokenize Replace a card's primary account number (PAN) with a unique digital token that stands in for the real card during a transaction. When a cardholder adds a card to Apple Pay or Google Pay via push provisioning, the wallet provider stores a device-specific token rather than the underlying PAN, so the real card number isn't exposed on the device or shared with merchants. field to your client and into the SDK component. The token is single-use and short-lived: every time you mount a display component, fetch a fresh GET /managed_cards/{id} server-side.
The plain value is rendered inside the SDK's sandboxed component - it never enters your application's JavaScript context, native code, or backend logs.
For the per-component request and code samples, follow the SDK guides:
- Web - card components and login components
- iOS - card components and login components
- Android - card components and login components
- React Native - card components and login components