---
title: "3DS Management"
slug: "3ds-management"
updated: 2026-07-09T07:01:38Z
published: 2026-07-09T07:01:38Z
canonical: "www.documentation.paynetics.digital/3ds-management"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://www.documentation.paynetics.digital/llms.txt
> Use this file to discover all available pages before exploring further.

# 3DS Management

3D Secure (3DS) is a protocol used to authenticate cardholders during online card payments. It helps reduce fraud and supports regulatory requirements such as Strong Customer Authentication (SCA).

## When 3DS is required

3DS authentication can be:

- **Frictionless**, where no user interaction is required
- **Challenge-based**, where the user must actively authenticate

## Types of authentication

Cards can be enrolled for one or both methods. When both are enabled, biometric authentication takes priority.

In case both methods are enabled, cardholders can choose the preferred one for each payment.

### SMS One-Time Password (OTP) and Static Password

Authentication is performed using an SMS-delivered OTP and a static password set by the cardholder. This method requires a verified phone number for the end customer.

### Biometric Authentication

Biometric authentication can be integrated into a partner’s mobile application. Paynetics sends an authorisation request via webhook, which the partner must present to the end customer. The customer can approve or reject the transaction using Strong Customer Authentication (SCA). Once approved, the partner must confirm authorisation via API.

## 3DS page modifications

*Additional costs may apply on the Partner side. Please contact the Paynetics Project Manager or Account Manager to support you with providing a quotation.

## *What* ***CAN*** *be customized*

### A. Text content (within strict limits)

Across almost all screens (Choice, OTP, OOB, Biometric, KBA, Error, Blocked):

- **Headline text**
  - Typically **45–50 characters**
- **Body / message text**
  - Up to **350 characters** (browser & most native flows)
  - Some native error / fail screens: **170 characters**
- **Error messages**
  - OTP errors (empty input, incorrect code, max retries)
  - OOB / Biometric validation errors
- **Button labels**
  - e.g. *Submit*, *Continue*, *Resend code*, *Close*
- **Informational expandable text**

You **cannot invent new replaceables**, but you **can include or exclude** supported ones in your message text:

Supported replaceables include:

These count toward the **350-character limit**
  - “Need help?”, “More information” sections

### B.Replaceable (dynamic) values
  - `{Merchant Name}`
  - `{Purchase Amount}` (omit for NPA flows)
  - `{Date}` (format selectable: `mm/dd/yyyy` or `dd/mm/yyyy`)
  - `{Masked PAN}`
  - `{Credential Type}` (SMS, email, app, etc.)
  - `{Credential Text}` (masked phone/email)

### C. Optional elements (show / don’t show)

You can configure visibility of:

- **Authentication methods**
  - SMS, Email, OOB App, Biometric, Voice (if supported)
- **Optional buttons**
  - “Choose another method”
  - “Having trouble?”
- **Expandable informational links**
  - Browser: only on Choice & Validate
  - Native app: available on all screens
- **Fail with Feedback / Blocked / Error screens**

### D. Branding
  - These are optional flows
  - **Issuer logo** (required)
  - **Network logo** (Visa / Mastercard placement fixed)
  - Logo format: **PNG with transparency**, recommended **200×70 px**

## What **CANNOT** be customized

### A. Screen structure & layout

You **cannot change**:

- Screen flow or order
- Zones (Header, Branding, Challenge, Info)
- Field placement (OTP input, buttons, errors)
- Visual hierarchy

### B. Mandatory buttons & labels

The following **must appear and are not editable** (text change only allowed via translation):

- **EXIT**
- **CONTINUE** (Native App OOB & Biometric)
- **CLOSE** (Blocked / Error / Fail screens)

### C. Authentication logic & behavior

You **cannot control**:

- OTP generation / retry logic
- Max resend attempts
- When a card becomes blocked
- When Fail with Feedback vs Error is triggered
- Frictionless vs Challenge decisioning

### D. Dynamic RDX response content

- RDX response text (shown on Fail / Blocked / Error screens)
- Returned from backend
- **Not editable in templates**

### E. Styling & visual design

You **cannot customize**:

- Fonts
- Colors
- Button shapes
- Icons
- Spacing
- Animations

Only **content**, not **design system**, is customizable.

A cardholder authentication protocol used during online card payments. 3DS reduces card-not-present fraud and supports regulatory requirements including Strong Customer Authentication. Authentication can be frictionless (no user interaction required) or challenge-based (the user must actively verify the transaction).

One-Time Password. A single-use numeric or alphanumeric code delivered to a cardholder—typically via SMS—as one factor in a Strong Customer Authentication flow. OTPs are time-limited and invalidated after a single use.

Strong Customer Authentication. A regulatory requirement under PSD2 mandating that electronic payments are authenticated using at least two independent factors: something the user knows, something the user has, and something the user is. SCA is enforced at checkout via 3DS for card payments.

A **Partner** is the entity that integrates Paynetics’ services and offers them to end customers.

Partners operate within their own instance and manage users, merchants, applications, and programs. They define fees, user flows, and configurations within the limits of their contractual agreement and may be responsible for KYC or KYB processing.

The partner is the primary integrator and owner of the end-to-end solution built on Paynetics.

An Account status indicating the account is restricted. Debits are not permitted; credits may be permitted depending on the reason for blocking. Blocking is reversible. All Virtual Accounts linked to a Blocked Payment Account are also blocked.