If EMVCo adopts its verifiable digital credential framework as a standard, you'll need a policy for accepting, validating, and processing these credentials at checkout. This template provides a starting point before the standard is finalized.
Purpose of the Template
This policy template outlines how your organization will manage verifiable digital credentials during card-not-present transactions once EMVCo's framework is adopted. It includes credential acceptance criteria, validation procedures, fallback authentication methods, and liability considerations.
You're developing this now because the framework is open for industry feedback until July 23. Early adopters who comment on the standard will influence its final form. Even if you don't implement it immediately, having a draft policy helps identify integration gaps, training needs, and system requirements before vendors start shipping solutions.
This isn't a replacement for your existing 3D Secure or step-up authentication policies. It's a parallel track that may eventually supersede them if the liability shift occurs.
Prerequisites
Before customizing this template, ensure:
- Your payment gateway or processor plans to support EMVCo's digital credential standard (most won't commit until the framework is finalized, but ask anyway).
- You've identified which checkout flows will accept digital credentials (web, mobile app, recurring billing, in-app purchases).
- Your fraud prevention team understands the difference between verifiable credentials and existing wallet tokens. Credentials prove identity attributes, while tokens substitute for PANs.
- You have a Multi-Factor Authentication policy defining acceptable authentication factors under PCI DSS 4.0 Requirement 8.4.2.
- Your legal team has reviewed whether accepting digital credentials changes your liability position under current card brand rules.
If these pieces aren't in place, you can still draft the policy. Mark sections with [PENDING: vendor confirmation] or [PENDING: legal review] to revisit later.
The Template
VERIFIABLE DIGITAL CREDENTIAL ACCEPTANCE POLICY
Version 1.0 Draft | Effective [DATE]
1. SCOPE
This policy applies to all card-not-present payment channels where customers
present verifiable digital credentials for authentication during checkout.
In-scope channels:
- [List your channels: web checkout, mobile app, phone orders, etc.]
Out-of-scope:
- Card-present transactions (chip and contactless already use EMV standards)
- Transactions where the customer explicitly declines credential presentation
- [Add exclusions specific to your business]
2. CREDENTIAL ACCEPTANCE CRITERIA
We will accept digital credentials that meet these requirements:
a) Credential Format
- Structured according to EMVCo's Digital Credential Framework (once finalized)
- Presented from a wallet provider we've verified supports the standard
- Contains minimum required attributes: [cardholder name, billing address,
credential expiration date]
b) Wallet Provider Verification
- Wallet provider appears on our approved provider list (maintained by
[team name])
- Provider demonstrates compliance with EMVCo's framework through [certification
body TBD]
- We've completed technical integration testing with the provider
c) Credential Validity
- Credential is not expired
- Credential issuer (typically the card-issuing bank) is reachable for
real-time validation
- No negative signals from our fraud prevention system
3. VALIDATION PROCEDURE
When a customer presents a digital credential:
Step 1: Technical Validation
- Verify credential format matches EMVCo standard
- Confirm cryptographic signature from issuing authority
- Check credential expiration timestamp
- [If validation fails: proceed to Section 5, Fallback Authentication]
Step 2: Fraud Screening
- Submit credential attributes to fraud prevention system
- Apply standard fraud rules ([velocity checks](/glossary/velocity-checks), [device fingerprinting](/glossary/device-fingerprinting), etc.)
- [If fraud score exceeds threshold: proceed to Section 5]
Step 3: Authorization
- Submit payment authorization with credential reference
- Include credential validation status in authorization message
- [Your processor will need to support this; confirm field mappings]
Step 4: Documentation
- Log credential acceptance event in [system name]
- Record: credential ID, wallet provider, validation timestamp, authorization
response
- Retain for [X months] per PCI DSS Requirement 10.7
4. LIABILITY CONSIDERATIONS
Current state (pre-standard adoption):
- Accepting digital credentials does NOT shift fraud liability to issuer
- We remain liable for fraudulent transactions even if credential validated
- Monitor EMVCo and card brand announcements for liability shift provisions
If liability shift is introduced:
- [Legal team to define]: criteria for qualifying transactions
- [Compliance team to define]: documentation requirements to claim shift
- [Finance team to define]: chargeback handling procedures
5. FALLBACK AUTHENTICATION
If credential validation fails or customer declines to present credential:
Primary fallback: 3D Secure (current process)
Secondary fallback: [Your existing step-up authentication method]
Do NOT lower authentication requirements just because credential path failed.
6. EXCEPTION HANDLING
Scenarios requiring manual review:
- Credential validates but fraud score is borderline
- Wallet provider is new and not yet on approved list
- Customer disputes a transaction where credential was accepted
- [Add scenarios specific to your risk appetite]
Exception authority: [Role/team name]
Review SLA: [Timeframe]
7. TRAINING REQUIREMENTS
Before implementing:
- Fraud analysts: complete training on credential validation signals
- Customer service: understand how to explain credential requests to customers
- Development team: complete integration testing with [number] wallet providers
- [Other teams as needed]
8. MONITORING AND REPORTING
Track these metrics monthly:
- Credential presentation rate (% of eligible transactions)
- Credential validation success rate
- Fraud rate for credential-authenticated vs. non-credential transactions
- Customer friction indicators (cart abandonment at credential prompt)
- [Your KPIs]
Report to: [Stakeholder group]
Review frequency: [Monthly until stable, then quarterly]
9. POLICY REVIEW
Review triggers:
- EMVCo finalizes standard (expected [DATE if known])
- Card brands announce liability shift provisions
- We complete integration with [number] wallet providers
- Fraud rate changes by more than [threshold]
- Annually at minimum
Owner: [Role]
Approvers: [Roles]
Customizing the Template
Section 1 (Scope): Clearly list every checkout flow where customers could present credentials. If starting with web-only, state that explicitly. Don't assume mobile will work the same way.
Section 2 (Acceptance Criteria): The "approved provider list" is crucial. You can't validate credentials from every wallet claiming EMVCo compliance. Start with major providers like Apple, Google, and Samsung if they adopt the standard. Define who maintains this list and how often it's reviewed.
Section 3 (Validation Procedure): Your fraud prevention system likely doesn't have credential validation built in yet. Work with your vendor to understand what signals they'll extract from credentials. If they can't commit to specific fields, note that and revisit quarterly.
Section 4 (Liability): This section will change significantly if card brands introduce a liability shift similar to 3D Secure. Until then, assume you're liable and document everything. Your legal team should monitor EMVCo announcements and card brand rule changes.
Section 5 (Fallback): Don't eliminate 3D Secure just because you're accepting credentials. You'll need it for customers who don't have compatible wallets or who decline to share credentials.
Section 9 (Review Triggers): Set a calendar reminder for July 23 (the feedback deadline) to check whether EMVCo published an updated draft. If the framework changes materially, you'll need to revise acceptance criteria.
Validation Steps
Before finalizing this policy:
Technical Feasibility Check: Can your payment gateway actually receive and validate credentials structured per EMVCo's framework? Get written confirmation from your processor, not just a sales pitch.
Fraud Rule Audit: Review your existing fraud rules to identify which ones rely on authentication methods. You may need new rules specifically for credential-authenticated transactions.
Chargeback Procedure Review: Walk through a disputed transaction scenario with your chargeback team. What evidence will you submit if a customer claims they didn't present a credential? The validation logs in Section 3, Step 4 are your proof.
Customer Communication Review: Draft the checkout page language explaining why you're requesting a credential. Test it with customers unfamiliar with "verifiable digital credential" to prevent cart abandonment.
Cross-Policy Consistency Check: Compare this policy to your existing authentication policies. Ensure the credential path doesn't create a lower security bar than 3D Secure. If your 3D Secure policy requires MFA per PCI DSS 4.0 Requirement 8.4.2, the credential path should too.
Stakeholder Sign-Off: Get explicit approval from fraud, legal, compliance, and engineering before implementation. If the standard changes after July 23 and you've already built integrations, someone will ask why you moved so fast.
This template isn't final until EMVCo's framework is finalized. Treat it as a living document and update it whenever the standard evolves.
