PCI Scope, Payment Idempotency and 3DS2 at a Cross-Border Marketplace

Current scope: the web app, mobile API, MySQL, backups, logs and the key-management process all touch card data. Storing the PAN - even encrypted - puts the company in PCI DSS SAQ D scope, with key management, segmentation, file-integrity monitoring, quarterly ASV scans and annual audits. Application-managed AES keys in the same environment are a serious weakness: an attacker with application access can decrypt the table.

Target architecture

• Use the acquirer's hosted payment page, hosted fields or iframe so the PAN never enters the company's servers. The browser posts directly to the PSP; the company receives a token.
• For mobile, use the PSP SDK rather than a custom API that receives card data.
• Store only the token, last four digits, expiry and card brand. Use network tokenization for better authorization rates and card-update handling.
• Segment any remaining cardholder-data environment; remove card data from logs, error traces and backups.
• Move to SAQ A or SAQ A-EP, and rotate any keys that may have been exposed.

Never store: the CVV/CVC after authorization, full track data, PIN block, or unencrypted PAN. If a PAN must be retained for a legitimate reason, truncate it, tokenize it, encrypt it with a KMS/HSM key and isolate the segment - but the better answer is not to retain it.

CTO constraint: hosted fields can be embedded without changing the order API or the checkout UX. The rewrite is bounded to the payment step and removes a large audit and breach exposure, so it can be justified before the holiday season.

Flow

1. Checkout creates an order with a server-generated idempotency key and a PENDING_PAYMENT state.
2. The client obtains a payment token from the PSP via hosted fields or SDK; the server never sees the PAN.
3. Authorize with the idempotency key. Store the PSP authorization ID, amount, currency and status. A retry with the same key must return the original result, not create a new authorization.
4. On authorization success, move to AUTHORIZED and reserve inventory; on failure, release inventory and mark FAILED.
5. Capture at shipment, not at checkout, to avoid capturing for unshipped goods. Partial capture is allowed; each capture has its own idempotency key.
6. Refunds reference the original capture ID and use a refund idempotency key; allow partial refunds but never exceed the captured amount.
7. Webhooks: verify the signature, insert the event into a payment_event table with a unique constraint on (provider, event_id), process asynchronously, and return HTTP 200 for duplicates. Reconcile daily against the PSP settlement file.

Where duplicate charges can occur

• Client retries after a timeout where the authorization actually succeeded.
• Webhook retries processed twice.
• Capture retries without a capture idempotency key.
• Refund retries or refunding a capture twice.
• Manual customer-service actions outside the state machine.

Controls: idempotency keys at the PSP, unique constraints locally, a guarded order state machine, and a rule that a timeout is not a failure - query the PSP by idempotency key before retrying. Alert on any order with more than one successful authorization or capture.

Blocking entire countries destroys conversion without addressing the fraud source; it also pushes legitimate customers to competitors.

3DS2 and SCA

• Apply 3DS2 to EU/UK card transactions and request frictionless authentication; the issuer decides whether to challenge.
• Use the low-value exemption (under €30, subject to cumulative limits) and Transaction Risk Analysis only where the acquirer's fraud rate qualifies. Do not request exemptions on high-risk orders.
• For subscriptions and card-on-file, use merchant-initiated transaction flags and network tokens.
• Successful 3DS shifts liability for many fraud chargeback codes, but not all; it complements rules rather than replacing them.

Fraud rules

• Velocity per card, device, IP and email.
• BIN country versus IP country versus shipping country mismatch.
• AVS/CVV mismatch, disposable email, first-order high value, device-fingerprint reuse.
• Score and route to allow, challenge via 3DS, manual review or block. Replace blanket country blocks with segment-level rules and a holdout test in one blocked country.

Chargeback management

• Collect delivery proof, IP, device ID, 3DS result and customer communication.
• Respond within network deadlines; track reason codes by country and feed them back into rules.

Monitoring

• Fraud rate and chargeback rate by country, channel and payment method.
• 3DS challenge rate and frictionless rate.
• Conversion by segment and false-positive rate.
• Manual-review queue age and overturn rate.

Target 0.6% by combining 3DS on risky orders, stricter rules on high-risk BINs, and manual review above a value threshold. Expand the holdout only if fraud stays below 0.9% and conversion recovers.