FinWiki Public-source finance field guide
日EN

Japan card security and authentication controls

Confidence Likely
Updated 2026-05-22
Review by 2026-11-22
Sources 11 Machine-translated Original (JA)
#payments#credit-card#security#EMV-3DS#PCI-DSS#PSP
On this page

Overview

Japan EC card security is not only “3-D Secure.” The useful control stack is: card-data protection -> merchant vulnerability control -> EMV 3-D Secure authentication -> fraud monitoring -> acquirer / PSP / merchant information sharing -> chargeback and remediation.

Use this page with card issuer / acquirer / processor split, card acquiring stack, PSP settlement risk, credit / card operator registry, and Installment Sales Act 2020 amendment.

Guideline Snapshot

Version / routePublic-source roleWiki reading
METI 2025-03-05 releaseAnnounces the credit-card security guideline revision.Public policy anchor for EC merchant security strengthening.
Japan Credit Association guideline 6.1Main current public guideline source for card-security controls.Use for non-retention, EC security, EMV 3-D Secure, and fraud-control vocabulary.
PCI DSSInternational card-data security standard.Use for cardholder-data environment and merchant / PSP security controls.
EMV 3-D SecureAuthentication protocol / messaging standard.Use for risk-based authentication and challenge-flow analysis.
JCB merchant / brand pagesPlain-language model of issuer, acquirer, brand, merchant, and authentication roles.Use to separate flattening all parties into “card company.”

Actor And Responsibility Map

ActorJapanese / market termCore responsibilitySecurity artifact
IssuerIssuerCardholder screening, authorization, ACS / authentication decision, billing, fraud monitoring.Authorization logs, ACS result, cardholder dispute / fraud monitoring.
Card brand / networkInternational brand / brandNetwork rules, directory routing, brand security rules, interoperability.Scheme rules, directory-server routing, brand compliance.
AcquirerMerchant underwriting, merchant contract, settlement, chargeback routing.Merchant due diligence, security status, chargeback monitoring.
PSP / gatewayPayment agency / PSPPayment page, tokenization, 3DS Server integration, transaction data, reconciliation.Tokenization design, 3DS transaction logs, fraud filters.
MerchantEC MerchantSite security, customer authentication UX, shipping / refund controls, evidence retention.Vulnerability controls, order logs, delivery / refund evidence.
3DS Server / DS / ACS3-D Secure componentsData transfer, directory routing, issuer authentication, challenge / frictionless flow.AReq / ARes / challenge result, ECI / CAVV style authentication data.

Control Stack

LayerThreatControl objectivePrimary ownerSecondary owner
Card-data protectionCardholder data leak.Avoid storing card data where possible; keep PCI scope controlled.Merchant / PSPAcquirer
Tokenization / non-retentionRaw card data exposure.Replace card data handling with token / redirect / JavaScript-token models.PSPMerchant
Merchant vulnerability controlEC-site compromise, formjacking, account takeover.Keep EC site, plugins, admin accounts, and payment pages hardened.MerchantPSP / EC system provider
EMV 3-D SecureUnauthorized card-not-present use.Add risk-based issuer authentication and challenge flow.Issuer / ACSMerchant / PSP / brand
Fraud monitoringCredit master / BIN attack, abnormal order pattern, reshipping fraud.Detect and stop suspicious transactions and delivery.Issuer / acquirer / PSPMerchant
Chargeback / disputeLoss allocation and evidence failure.Preserve order, authentication, delivery, refund, and communication evidence.Acquirer / merchantIssuer / PSP

EMV 3-D Secure Route

StepComponentResearch question
CheckoutMerchant / PSPIs transaction data complete enough for risk-based authentication?
3DS request3DS ServerIs the PSP or merchant integrating the 3DS Server correctly?
Directory routingDirectory ServerWhich brand / card route receives the authentication request?
Issuer decisionACS / issuerIs the flow frictionless, challenged, declined, or unavailable?
AuthorizationIssuer / acquirerHow are authentication result and authorization result combined?
Dispute / liabilityIssuer / acquirer / merchantDoes the authentication result actually change liability or only add evidence?

3-D Secure reduces card-not-present fraud risk, but it does not replace merchant screening, card-data protection, account-takeover controls, delivery controls, or chargeback evidence. That is why this page is linked with PSP settlement risk rather than as a protocol-only note.

Non-retention, Tokenization, And PCI DSS

Integration patternCard-data exposureWiki reading
Redirect payment pageMerchant redirects to PSP / acquirer hosted page.Lower merchant card-data exposure if implemented correctly.
JavaScript token modelCard data is sent from browser to PSP / tokenization endpoint.Merchant still needs site-security controls because page compromise can alter scripts.
Server-side card handlingMerchant server receives card data.Highest PCI and operational burden; needs strong evidence before describing as compliant.
Stored credential / recurring billingToken or credential-on-file used for later payments.Needs consent, lifecycle, cancellation, and fraud monitoring controls.

EC Merchant Fraud Controls

PatternControl
Credit master / BIN attackRate limits, authorization pattern monitoring, issuer / acquirer alerts, payment-page controls.
Account takeoverLogin protection, device / behavior monitoring, step-up authentication, password-reset monitoring.
High-risk deliveryAddress / shipping change monitoring, delivery hold, manual review, cancellation / refund control.
Refund abuseRefund approval workflow, settlement reconciliation, merchant dashboard permission control.
Site compromiseVulnerability scanning, patching, script integrity checks, admin MFA, incident response.

JapanFG Relevance

Card-security analysis is routed through issuer / acquirer / PSP roles rather than through a single “credit card company” label:

Red Flags For Wiki Research

  1. A source says “card company” but does not say whether it means issuer, acquirer, brand, processor, or PSP.
  2. A merchant claims 3-D Secure support but has no evidence for vulnerability controls, tokenization, or fraud operations.
  3. A PSP claims tokenization but the merchant page can still expose card data through compromised scripts.
  4. A fraud metric is quoted without denominator: transaction value, order count, approval rate, challenge rate, chargeback rate, or fraud amount.
  5. A liability-shift statement is treated as a complete loss guarantee.

Sources

  • METI: credit-card security guideline revision release and credit-transaction policy page.
  • Japan Credit Association: Credit Card Security Guidelines 6.1 and document index.
  • JCB: merchant EMV 3-D Secure notice and brand / card-payment actor explanation.
  • PCI Security Standards Council: PCI DSS overview and Japanese document library.
  • EMVCo: EMV 3-D Secure public standard overview.
  • Payments Japan and FSA / PPC / METI public security-advisory materials.

Discovery

Keep reading

Related

Read next

Links here