Add an authentication control
Provide supported transaction context to the issuer-side assessment and authenticate the cardholder when required.
Risk Service
3D Secure
Coordinate supported EMV 3-D Secure authentication for card-not-present journeys, from requestor-side integration to eligible issuer-side ACS deployments.
For merchants, PSPs, acquirers, platforms, issuers and card programs defining online cardholder authentication roles.
Frictionless flowChallenge flowBrowser and appIssuer-side ACS
Service outcomes
Place authentication correctly in the payment journey.
These are operating goals, not performance guarantees. Results depend on scope, participants, implementation and customer operations.
Design for checkout continuity
Plan frictionless and challenge paths around the channel, device, timeout, cancellation and return experience.
Support authentication obligations
Use supported 3D Secure flows as one part of scheme, SCA, risk and regional compliance planning without assuming compliance.
Coverage & fit
Confirm protocol, scheme, channel and participant compatibility.
Versions, schemes, processors, SDK responsibility, challenge methods, regions, exemptions and certification scope are specific to the deployment.
Requestor-side integration
Supported merchant, PSP, acquirer or platform authentication requests and result handling.
Issuer-side ACS
Eligible issuer or card-program evaluation and challenge coordination included only where contracted.
Browser and app channels
Supported browser or mobile-app journeys with explicitly allocated SDK, redirect and return responsibilities.
Payment handoff
Return protocol status and applicable authentication data to a separately managed authorization flow.
Authentication is not authorization
A successful authentication does not approve a payment. The relevant issuer makes a separate authorization decision if processing continues.
Priority use cases
Use 3D Secure in compatible card-not-present journeys.
E-commerce and marketplaces
Coordinate supported authentication context and challenge return paths around checkout.
Travel and reservations
Plan authentication for compatible booking, cross-border and higher-value card-not-present journeys.
Stored-credential setup
Define authentication around the initial customer-initiated setup and the later payment model.
Issuer and card programs
Evaluate eligible ACS responsibilities alongside issuer policy and cardholder operations.
Core capabilities
Scope distinct requestor-side and issuer-side behaviors.
A customer receives only the roles, components, versions, channels and methods expressly confirmed in its deployment.
Authentication request
Collect and exchange supported account, device, channel, merchant and transaction context.
Frictionless flow
Return an issuer-side authentication result without cardholder interaction when the ACS assessment permits it.
Challenge flow
Coordinate supported challenge presentation, cardholder action, timeout, cancellation and return handling.
Issuer-side ACS
Evaluate requests under issuer policy and select the supported authentication path for eligible deployments.
Result and event handling
Map protocol status, applicable authentication values, callbacks, errors and downstream references.
Operational visibility
Define records, monitoring, exception handling and support escalation across the participating systems.
Integration & deployment
Place 3D Secure correctly in the payment stack.
Technical design identifies the supplied component, protocol role, credentials, certificates, channel behavior, events and authorization handoff.
Request technical documentation →Standalone or connected
Evaluate a standalone path or connect with Vellfi Orchestration and Gateway where separately supported.
Browser journey
Define collection, redirects or embedded challenge, timeout, accessibility and return behavior.
App journey
Allocate any SDK, deep-link, challenge and app-to-backend responsibilities only where supported.
Test and release
Exercise frictionless, challenge, failure, cancellation, timeout and authorization handoff paths before rollout.
How it works
Authenticate inside the payment flow, not instead of it.
The issuer-side ACS determines the authentication path; downstream payment authorization remains separate.
- 1
Collect context. Assemble the supported account, device, channel, merchant and transaction data.
- 2
Send request. Exchange the authentication request through the supported 3D Secure participants.
- 3
Evaluate risk. The issuer-side ACS applies issuer policy and available context.
- 4
Authenticate. Complete frictionlessly or move to a supported cardholder challenge.
- 5
Return status. Return protocol outcome and applicable authentication data to the payment flow.
- 6
Request authorization. If processing continues, submit a separate authorization request to the relevant participant.
Illustrative scenario—not a customer case study
A travel booking platform is reviewing authentication across card-not-present channels.
Context
Browser and app bookings include different participants, return paths and operational handling for failed or abandoned authentication.
ChallengeThe team needs one explicit model for request context, issuer-side outcomes, customer experience and authorization handoff.
Possible approach
Vellfi scopes the supported requestor integration, flow events and, where eligible, issuer-side ACS responsibilities with the payment participants.
Potential operating effectThe platform has defined authentication and exception paths. Fraud, approval, liability and SCA outcomes still depend on scheme rules, implementation and participant behavior.
Responsibilities & availability
Keep checkout, authentication and payment responsibilities distinct.
Merchant / Requestor
Provides lawful request data, checkout and challenge experience, and agreed result handling.
3D Secure components
Exchange supported protocol messages and return the authentication result.
Issuer / ACS
Applies issuer policy, selects the path and returns the protocol outcome.
Payment participants
Handle the separate gateway, acquiring, processing and authorization flow.
No automatic liability or compliance outcome
Liability treatment and SCA depend on scheme rules, transaction and exemption type, protocol result, processing data, geography and participant compliance.
Next step
Review your 3D Secure flow.
Share the participant roles, checkout channels, payment stack and authentication requirements without sending card data or live transaction records.
FAQ
3D Secure: common questions
What is EMV 3-D Secure?
It is a protocol family that lets payment participants exchange transaction context so an issuer can assess and, when needed, authenticate a cardholder.
What is an ACS?
An Access Control Server is the issuer-side component that evaluates authentication requests, selects a frictionless or challenge path and returns the result.
Does successful authentication mean approval?
No. Authentication and authorization are separate decisions.
Will every customer see a challenge?
No. The issuer-side assessment determines the path. Vellfi does not promise that a transaction will be frictionless or challenged.
Does 3D Secure guarantee liability shift?
No. Liability depends on scheme rules, result, transaction type, exemption, processing data, geography and participant compliance.
Does 3D Secure guarantee SCA compliance?
No. It can support an SCA design, but compliance depends on the full implementation and participant responsibilities.
How are recurring payments handled?
The initial customer-initiated setup and later merchant-initiated transactions can have different authentication and liability treatment.
Which versions and schemes are supported?
Compatibility is deployment-specific and must be confirmed during technical scoping.