Learning Objectives

• ✅ Explain how Hosted Payment Pages (HPP) reduce PCI DSS scope for merchants.
• ✅ Describe the role of tokenization in enabling "saved card" features securely.
• ✅ Evaluate the function of 3-D Secure in mitigating fraud and payment disputes.
• ✅ Connect these technical choices to business outcomes like conversion rates and operational efficiency.

The Challenge: Moving Beyond Local Payments

Composite/illustrative case: no named retailer evaluation or measured outcome source was supplied.

A Nepali online retailer needed to expand its payment options beyond the standard methods.

The Security Hurdle: PCI DSS

Directly handling card data is complex, expensive, and high-risk.

Solution Part 1: The Hosted Payment Page (HPP)

The merchant chose an integration method that keeps card data completely off their servers.

Result: The merchant's system never sees or touches the raw card number. ⚡

🎬 Watch: Whose Page Takes the Card?

The Customer Returns—but Is the Order Paid?

Scenario: the browser returns to /order-success, but the server has not confirmed payment. Should the warehouse ship?

1. Treat the browser return as a user-experience signal, not final payment evidence.
2. Verify a signed provider notification or retrieve payment status through the provider's authenticated server API.
3. Match the merchant order ID, expected amount, currency and final payment state.
4. Handle duplicate notifications idempotently: one payment event must not ship two parcels.

If status is uncertain, show “Payment being checked—please do not pay again yet.” Reconcile before fulfilment.

Reducing PCI Scope: SAQ A vs. SAQ D

This HPP approach drastically simplifies PCI compliance.

SAQ Types Are Not Merchant Levels

• SAQ type: selected from the actual payment architecture and all eligibility criteria. Merchant validation levels are a separate card-brand/acquirer concept.
• Redirect/HPP: can support SAQ A eligibility; outsourcing does not remove all merchant responsibilities.
• Provider-hosted iframe: is not automatically SAQ A-EP. The origin of payment-page elements and the full implementation matter.
• Merchant-generated form: can change scope even when card data posts directly to a provider rather than the merchant's server.

Confirm the current questionnaire and evidence with the acquirer/compliance-accepting entity. A three-question classroom quiz cannot certify eligibility.

Solution Part 2: Tokenization for Repeat Customers

How can the site offer a "save card" feature without storing card data?

A Token Reduces Exposure, Not Responsibility

• A payment token references protected card information; the merchant need not store the full card number to support repeat payments.
• A random token generated in this browser demo is a visual analogy—not a real vault, encryption scheme or production payment credential.
• An attacker with a usable token plus compromised merchant credentials may still abuse permitted payment operations. Protect access, API keys and customer accounts.
• Ask who can use the token, where it is accepted, how it can be revoked and whether future payments need customer authentication.

Use fake/test data only in class. Never store card verification codes after authorisation; tokenisation is not permission to retain CVV.

Solution Part 3: 3-D Secure (3DS)

To prevent fraudulent transactions and chargebacks, 3-D Secure was integrated.

Benefit: Liability for fraudulent chargebacks often shifts from the merchant to the card-issuing bank.

What 3DS Does—and Does Not—Promise

• Authentication: 3DS helps the issuer assess the shopper's identity through a frictionless or challenged flow.
• Authorisation: a distinct payment decision; the issuer may still decline an authenticated transaction.
• Liability shift: depends on scheme rules, eligibility and authentication results. It does not remove every dispute category, including non-delivery disputes.
• SCA: a regulatory concept in relevant jurisdictions, not a synonym for every OTP challenge or a blanket Nepal requirement.

The simulator's weights, thresholds and “soft/hard” labels are illustrative. They do not disclose any bank's real fraud algorithm.

🎬 Watch: Silent Pass or Challenge

Operational Impact: Automated Reconciliation 📊

Accepting a new payment type adds operational complexity. Automation is key.

• The payment gateway provides a daily settlement file (CSV, XML, or via API).
• This file lists all successful transactions and fees for that day.
• An automated script was developed to ingest this file and match it against orders in the internal accounting system.
• This eliminates hours of manual work and reduces human error.

Worked Example: Reconcile the Payout

Illustrative daily batch: A captured Rs 3,000; B captured Rs 5,000; C declined Rs 2,000. Refund Rs 1,000 from A; fee 2% of captured value. No other adjustments.

1. How much was captured? 3,000 + 5,000 = Rs 8,000; C is excluded.
2. What is the fee under this assumption? 2% × 8,000 = Rs 160.
3. Expected payout? 8,000 − 1,000 − 160 = Rs 6,840.
4. If the bank shows Rs 6,740, what next? Investigate the Rs 100 difference using payout IDs, fee records and timing; do not invent a balancing transaction.

Real contracts may handle fees on refunds, reserves and settlement dates differently. Match by transaction and payout reference, not amount alone.

Practical Application: The Nepali Context

Original provider ownership, local-partner and Nepal availability examples below remain unverified; do not treat them as onboarding advice.

This HPP and Tokenization model is a standard for enabling card payments in Nepal.

Case Outcomes & Business Impact

Composite/illustrative case: no named retailer evaluation or measured outcome source was supplied.

Audit the Business Case Before Buying

Illustrative calculator defaults: 200 transactions × Rs 3,500 = Rs 700,000 revenue. The model assumes 2.5% chargebacks, 75% liability avoided and 8% extra sales.

• Model output: Rs 13,125 assumed avoided liability + Rs 56,000 extra revenue = Rs 69,125.
• That is not net profit: extra revenue must cover goods and fulfilment; integration, provider and authentication costs are omitted.
• If extra sales have a 25% contribution margin, they contribute Rs 14,000. Adding assumed avoided loss gives Rs 27,125 before new costs.
• Ask for measured baseline data and a pilot. The 75% and 8% assumptions are not published guarantees from a gateway or card network.

Key Takeaways

What are the core lessons from this implementation?

• 🎯 Prioritize PCI Scope Reduction: Always choose the integration method with the lightest possible compliance footprint. An HPP is often the best choice for non-enterprise merchants.
• 🔐 Never Handle Raw Card Data: Let the payment gateway's secure vault and tokenization system manage sensitive data.
• UX is Security: A clear, well-designed 3-D Secure flow and robust error handling are crucial for minimizing checkout abandonment.
• ⚙️ Think Beyond the Button: Plan for back-office operations like reconciliation from day one to ensure scalability.