Payment Trust in Tier-2: Tokenization, PCI DSS, and Audit Scope

By Nirmal Chandra Nayak, Cofounder | Prashanth Kumar Nagapaga, Cybsersecurity Architect | Technical Advisor December 12, 2025

In a marketplace handling financial transactions, payment security is not optional.

Customers trust you with their payment information. Merchants trust you with their payouts. Delivery partners trust you with their earnings. One security breach can destroy that trust permanently.

This is the story of how we built payment trust at CenterShops—the security architecture, the compliance decisions, and the trade-offs we made.

The Payment Challenge

When we launched CenterShops, we had to support multiple payment methods:

• UPI (PhonePe, Google Pay, Paytm) - preferred by most customers
• Credit/Debit Cards - for customers without UPI
• Cash on Delivery - for customers who preferred cash
• Wallets - for repeat customers who wanted faster checkout

Each payment method had different security requirements, compliance obligations, and operational complexity.

The Security Architecture We Built

We designed our payment architecture around three principles:

1. Never Store Sensitive Payment Data

We used tokenization to avoid storing raw card numbers, CVVs, or UPI credentials.

How it worked:

• Customer enters payment details in the app
• Payment details are sent directly to the payment gateway (Razorpay, PhonePe, Stripe)
• Payment gateway returns a token representing the payment method
• We store only the token, not the actual payment details
• For future transactions, we use the token to charge the customer

Why: Tokenization drastically reduced our PCI DSS compliance scope. We never touched raw payment data, so we did not need to secure it.

Trade-off: We depended on payment gateway availability. If the gateway was down, we could not process payments. But the security and compliance benefits outweighed this risk.

2. Minimize PCI DSS Audit Scope

PCI DSS (Payment Card Industry Data Security Standard) compliance is expensive and complex. We reduced our audit scope by:

Using hosted payment pages: For card payments, we redirected customers to the payment gateway's hosted page. The gateway collected card details, not our app.

Avoiding payment data in logs: We ensured that no payment details (even partial card numbers) appeared in application logs, error messages, or database backups.

Segmenting payment infrastructure: Payment processing happened in isolated services with restricted network access. Even if our main application was compromised, payment data remained protected.

Impact: Our PCI DSS audit scope was limited to network segmentation and access controls. We did not need to audit our entire application stack.

Trade-off: Hosted payment pages meant less control over the checkout experience. But the compliance cost savings were significant.

3. Secure Payout Processing

Merchants and delivery partners needed timely payouts. We built a secure payout system:

Bank account verification: Before the first payout, we verified bank account ownership using penny drop verification (sending a small amount and confirming receipt).

Payout approval workflow: Payouts above a threshold required manual approval from operations team. This prevented fraudulent payout requests.

Audit trail: Every payout was logged with timestamp, approver, and reason. This created accountability and helped with dispute resolution.

Automated reconciliation: We reconciled payouts with order data daily. Any discrepancies triggered alerts for investigation.

Impact: Reduced payout fraud and improved merchant trust. Merchants knew they would be paid accurately and on time.

Trade-off: Manual approval added processing time for large payouts. But it prevented costly fraud incidents.

The Compliance Decisions We Made

Beyond PCI DSS, we had to navigate other compliance requirements:

RBI Guidelines for Payment Aggregators

India's Reserve Bank of India (RBI) has strict guidelines for payment aggregators. We ensured:

• KYC for merchants: All merchants completed Know Your Customer (KYC) verification before receiving payouts
• Transaction limits: We enforced transaction limits per customer and merchant to comply with RBI norms
• Dispute resolution: We built a formal dispute resolution process with defined timelines

Why: Non-compliance could result in fines or loss of payment gateway access.

Trade-off: KYC verification added friction to merchant onboarding. But it was legally required.

GST Compliance

As a marketplace, we had to handle Goods and Services Tax (GST) correctly:

• GST collection: We collected GST on platform fees (commission charged to merchants)
• GST invoicing: We generated GST-compliant invoices for merchants and customers
• GST filing: We filed GST returns monthly with accurate transaction data

Why: Tax compliance is non-negotiable. Incorrect GST handling could result in penalties.

Trade-off: Added accounting complexity. We integrated with accounting software (Zoho Books) to automate GST calculations and filing.

Data Privacy (GDPR and India's Data Protection Laws)

We handled customer payment data, so we had to comply with data privacy regulations:

• Data minimization: We collected only the payment data necessary for transactions
• Data retention: We deleted payment tokens after customer account closure
• Data access controls: Only authorized personnel could access payment-related data
• Data breach notification: We had a process to notify customers and regulators in case of a breach

Why: Data privacy violations can result in fines and reputational damage.

Trade-off: Required investment in data governance and access control systems.

The Security Incidents We Prevented

We did not have a major security breach, but we did identify and prevent potential issues:

Incident 1: OTP Abuse Risk (Identified During Penetration Testing)

During an internal penetration test, we identified a vulnerability in our OTP (One-Time Password) system. An attacker could potentially trigger unlimited OTP requests, leading to SMS cost abuse or denial of service.

Solution: We implemented rate limiting on OTP requests (max 3 OTPs per phone number per hour). We also added CAPTCHA for repeated OTP requests.

Impact: Prevented potential SMS cost abuse and improved system resilience.

Trade-off: Added friction for legitimate users who needed multiple OTPs. But the security benefit was worth it.

Incident 2: Payment Webhook Validation

Payment gateways send webhooks to notify us of payment status (success, failure, refund). We initially trusted these webhooks without validation.

Risk: An attacker could send fake webhooks to mark orders as paid without actual payment.

Solution: We implemented webhook signature verification. Every webhook was signed by the payment gateway using a shared secret. We verified the signature before processing the webhook.

Impact: Prevented potential payment fraud.

Trade-off: Added complexity to webhook processing. But it was essential for security.

Incident 3: Insecure API Endpoints

During a security review, we found that some admin API endpoints (used for payout approval) were not properly authenticated. An attacker with network access could potentially approve fraudulent payouts.

Solution: We implemented role-based access control (RBAC) for all admin APIs. Only authorized users with specific roles could approve payouts.

Impact: Prevented unauthorized payout approvals.

Trade-off: Required refactoring of admin authentication logic. But it closed a critical security gap.

The Real Lesson

Payment security is not a one-time project. It is an ongoing discipline.

Here is what we learned:

Tokenization is your friend: Never store raw payment data. Use tokenization to reduce compliance scope and security risk.

Compliance is not optional: PCI DSS, RBI guidelines, GST, and data privacy laws are not suggestions. Build compliance into your architecture from day one.

Defense in depth: No single security measure is sufficient. Use multiple layers (tokenization, rate limiting, webhook validation, RBAC, penetration testing) to protect against different attack vectors.

Automate security testing: Manual security reviews are important, but automated tools (SAST, DAST, SCA) catch issues faster and more consistently.

Plan for incidents: Even with strong security, incidents can happen. Have a response plan, practice it, and be ready to act quickly.

Why This Matters to Employers

This experience demonstrates several critical capabilities:

Security Architecture: Designing systems that minimize risk through tokenization, segmentation, and defense in depth.

Compliance Thinking: Understanding regulatory requirements (PCI DSS, RBI, GST, data privacy) and building them into the product.

Risk Management: Identifying potential security issues through penetration testing and automated scanning, and prioritizing fixes based on risk.

Operational Security: Building processes (payout approval, audit trails, reconciliation) that prevent fraud and enable accountability.

Looking Ahead

The lessons from CenterShops payment security now inform how we approach ChittaTaxis:

• Tokenization for rider payment methods
• PCI DSS compliance through hosted payment pages
• Secure driver payout processing with bank account verification
• Automated security testing integrated into CI/CD
• Quarterly penetration testing to identify vulnerabilities

The core insight: In a marketplace, payment trust is the foundation. Without it, no amount of features, marketing, or operational excellence will save the platform.

Next in this series: Securing a Multi-Vendor Marketplace: Lessons from Penetration Testing