Payment Information Policy
Version 2.1 · Effective 2026-09-09
Suffle Online
Operated by Naucera Travel Private Limited
1. Purpose and Scope
This Payment Information Policy explains how Suffle Online handles payment-related information and payment processing for marketplace purchases and Suffle software/WhatsApp subscription purchases.
It is intended to explain the separation between customer marketplace payments and subscription billing, payment verification, financial records, refunds and security responsibilities.
This Policy supplements the Suffle Online Privacy Policy, Data Security & Protection Policy, Refund & Cancellation Policy, Subscription Policy and Terms & Conditions.
2. Company and Contact
Suffle Online is operated by Naucera Travel Private Limited.
Website: www.suffleonline.com
General Support / Grievance Email: info@flyshoppy.com
Grievance Officer: Mr. Roopal Jain, Managing Director
Grievance Officer Mobile: 9707669981
Grievance Officer Email: info@flyshoppy.com
Address: 707, N. T. Road, Nalbari-781435 (Assam), India.
3. Payment Processor
Suffle uses Razorpay for payment processing as configured for the platform.
Payment processing may involve Razorpay and relevant banking, card-network, UPI or other payment-service infrastructure.
Third-party payment providers may have their own terms, privacy notices, security controls and processing requirements.
4. Two Separate Payment Systems
Suffle maintains two distinct payment/financial flows:
1. Marketplace payments: Customer → Suffle → Razorpay → verified payment → marketplace order.
2. Suffle software / WhatsApp subscription payments: User → Suffle subscription checkout → Razorpay → verified payment → subscription entitlement.
These flows must remain logically and financially separate. A marketplace product purchase is not a WhatsApp/software subscription, and a WhatsApp/software subscription is not a marketplace order.
5. Marketplace Customer Payments
For a marketplace purchase, the customer selects products and proceeds through Suffle checkout.
The payment is processed through the configured Razorpay checkout/payment flow.
An order is confirmed only after Suffle's backend verifies the payment according to the applicable gateway verification mechanism.
Opening the payment page, submitting payment details, receiving a frontend success message or returning to Suffle does not by itself establish that the payment has been successfully verified.
6. Payment Verification
Suffle should perform payment verification server-side using the applicable Razorpay verification mechanisms, including webhook and/or signature verification where required by the implementation.
Payment events should be validated for authenticity, amount, currency, order/reference association and applicable status before an order or subscription entitlement is treated as paid.
Idempotency and duplicate-event protection should be used so that repeated gateway events do not create duplicate orders, refunds, entitlements or financial records.
7. Order Confirmation Rule
Marketplace orders are confirmed only after successful server-side payment verification.
Seller approval, customization approval, manual order creation, payment-page opening or frontend payment success does not by itself confirm an order.
Before verified payment, the transaction should remain in an appropriate payment-pending or unconfirmed state.
After verified payment, Suffle may mark the payment as Paid and the applicable order as Confirmed.
8. Failed, Cancelled or Expired Payments
Failed, cancelled, abandoned or expired payment attempts must not be represented as successful payments or confirmed orders.
Where supported, Suffle may retain an attempted payment record for reconciliation, fraud prevention, customer support or accounting, without treating the attempt as a completed purchase.
If a customer is charged but Suffle does not receive or verify the expected payment confirmation, the matter should be reconciled with the payment provider before the system represents the order as paid.
9. Payment Credentials and Sensitive Authentication Data
Suffle must not request or store payment authentication secrets such as UPI PIN, ATM PIN, payment PIN, banking password or CVV as ordinary Suffle customer data.
Customers should enter sensitive payment credentials only into the legitimate payment-provider interface presented through the supported checkout flow.
Customers must not send payment PINs, OTPs, CVV or banking passwords to Suffle support, sellers or Suffle AI.
10. Cards, UPI and Other Payment Methods
Available payment methods depend on the configured Razorpay/payment-provider capabilities and may change over time.
Suffle may support card, UPI, net banking, wallet or other methods where enabled by the payment provider and platform configuration.
Suffle should not display a payment method as available unless it is actually enabled and supported for the relevant transaction.
11. Payment Amount and Checkout Transparency
Before payment, Suffle should present the applicable amount based on the actual cart/order data, including applicable product prices, discounts, taxes and shipping/delivery charges where configured.
For customized or seller-approved products, the customer should be shown the final applicable price, including applicable shipping/delivery charges, before payment.
Suffle must not fabricate prices, discounts, taxes, shipping charges or payment amounts.
12. Multi-Seller Cart and Master Order
A customer may purchase products from multiple sellers through one checkout.
Suffle may maintain one Master Order with separate seller sub-orders.
The payment is associated with the central customer transaction and its corresponding master/sub-order records.
Seller access is restricted to the seller's own sub-order and authorised financial information.
13. Seller Settlement
Customer payment does not mean the seller is immediately entitled to settlement.
Seller settlement is governed by the separate Commission & Seller Settlement Policy and may depend on order status, return/refund conditions, platform commission, applicable deductions and other configured rules.
Suffle must maintain separate records for customer payments, commissions, refunds and seller settlements.
14. Marketplace Refunds
Marketplace refunds are governed by the applicable Refund & Cancellation Policy and return/replacement rules.
A refund should not be represented as completed until the relevant refund process is successfully initiated and, where applicable, confirmed through the payment provider.
Suffle should maintain auditable links between the original payment, refund request, refund transaction and relevant order.
15. Subscription Payments
WhatsApp/software subscription payments are separate from marketplace purchases.
A subscription entitlement becomes active only after the applicable subscription payment has been successfully verified.
Subscription duration, activation, expiry, cancellation and refund rules are governed by the separate Subscription Policy.
Super Admin may manually activate an eligible subscription where the platform provides such functionality, subject to internal authorisation and audit controls.
16. No Seller Payment Gateway
Sellers do not connect their own payment gateway to receive customer marketplace payments through Suffle.
Marketplace customer payments are processed through Suffle's configured payment flow.
Seller settlement occurs through Suffle's central financial system according to the applicable seller settlement rules.
17. No Cash on Delivery
Suffle's marketplace payment model does not support Cash on Delivery.
Where a product requires a custom or seller-confirmed price, the final amount must be established before payment through the supported Suffle payment flow.
18. Custom and Manual Orders
Sellers may create customer orders through Suffle when customers contact them through WhatsApp, phone, walk-in, social media or other channels.
Such manual/direct orders must use the same central Product, Order and Payment systems rather than a separate payment database.
A manual order can generate a Suffle/Razorpay payment request where configured.
Creating the manual order or sending the payment request does not confirm the order; confirmation occurs only after verified payment.
19. Customer Customisation Payments
For customized products, a seller may review the customer's requested customization and confirm the final price before payment.
Customer-uploaded customization files remain associated with the relevant request/order and are not public product media.
Payment should not be requested for a final custom price until the customer has been shown the applicable amount.
20. Payment Links and Payment Requests
Where Suffle generates a payment request or payment link, it should identify the relevant customer/order/subscription reference and amount.
Payment links should not be treated as paid merely because they were opened or shared.
Payment status must be derived from verified payment records.
21. Webhooks and Event Security
Payment-provider webhooks must be authenticated and validated according to the provider's supported mechanism.
Webhook processing should be idempotent and should protect against replay, duplicate and out-of-order events where relevant.
Unverified or malformed payment events must not change the authoritative payment or order state.
22. Reconciliation
Suffle should reconcile its payment records against the payment provider's transaction information where appropriate.
Discrepancies such as charged-but-unconfirmed payments, duplicate events, unexpected amounts, duplicate refunds or settlement differences should be flagged for investigation.
Financial reconciliation records should be protected and auditable.
23. Payment Security
Payment-related systems should follow the safeguards described in the Data Security & Protection Policy, including least privilege, secure secrets management, logging and access controls.
Payment-provider credentials, webhook secrets and API keys must not be exposed in public interfaces, seller dashboards, customer-visible logs or AI prompts.
24. AI and Payment Information
Suffle's Super AI may help customers understand verified payment, order or refund information where authorised.
AI must not invent payment success, payment failure, balances, refund status, charges, discounts or other financial facts.
AI must not request or retain prohibited payment authentication secrets.
Payment state must be obtained from the authoritative Suffle/payment system rather than inferred from a screenshot, conversation or frontend message when authoritative data is available.
25. Payment Information and Sellers
Sellers may receive only the payment/order information required for authorised marketplace operations.
Sellers must not receive a customer's full card credentials, UPI PIN, CVV, banking password or other prohibited payment authentication information.
Seller settlement information is separate from the customer's payment credentials.
26. Taxes, Invoices and Financial Records
Applicable taxes, invoices and financial records are generated or maintained according to the transaction configuration and applicable law.
Payment records may include transaction references, amounts, status, dates, refunds, commissions and settlement information.
Customers and sellers should rely on the transaction/invoice records generated by Suffle rather than AI-generated financial summaries where an authoritative record is available.
27. Payment Disputes and Chargebacks
Customers may raise payment disputes through Suffle support and, where applicable, through the relevant payment provider or issuing institution.
Chargebacks or payment disputes may affect order, refund and seller-settlement processing.
Suffle may place relevant financial records or settlements under review while a dispute is investigated.
28. Fraud and Risk Controls
Suffle may apply reasonable payment-risk and fraud-prevention controls, including transaction monitoring, velocity controls, verification checks and review of suspicious activity.
Certain risk-control rules and thresholds may not be publicly disclosed because disclosure could weaken fraud-prevention effectiveness.
Suffle may suspend or review transactions where fraud, abuse or security risk is reasonably suspected.
29. Payment Provider Availability
Payment processing may be affected by bank, UPI, card-network, Razorpay, internet, technical or other third-party outages.
Suffle does not guarantee that every payment method will always be available.
Temporary provider errors must not be represented as completed payments.
30. Data Retention and Deletion
Payment and financial records may need to be retained for accounting, reconciliation, fraud prevention, dispute resolution, legal and regulatory requirements.
Deletion of a customer account does not necessarily result in immediate deletion of financial records that Suffle is legally or operationally required to retain.
Detailed retention rules are addressed in the Privacy Policy and Account Deletion & Data Retention Policy.
31. Changes to Payment Processing
Suffle may modify supported payment methods, payment-provider configurations, verification mechanisms and payment features as the platform evolves.
Material changes should be reflected in applicable customer-facing information and policies.
32. Relationship with Other Policies
This Policy should be read with the Terms & Conditions, Privacy Policy, Data Security & Protection Policy, Subscription Policy, Refund & Cancellation Policy, Commission & Seller Settlement Policy, Custom & Personalised Products Policy and Seller Terms.
Where a specialised policy provides more specific payment or financial rules, that policy applies in addition to this Policy.
33. Policy Changes
Suffle may update this Policy when payment services, security practices, providers, technology or legal requirements change.
The current effective version should be maintained through Suffle's central legal/policy management system.
34. Legal and Implementation Note
This Policy describes Suffle's intended payment governance and must be aligned with the payment integration actually deployed.
Before launch or material changes, Suffle should verify Razorpay configuration, server-side verification, webhook/signature validation, idempotency, refund handling, reconciliation, access controls and applicable legal requirements.
This Policy should be reviewed by qualified Indian legal counsel and appropriate payment/security professionals before publication and before enabling material new payment functionality.
Critical Payment Rules
· Marketplace order confirmation occurs only after successful server-side payment verification.
· Opening a payment page or receiving a frontend success message is not sufficient proof of payment.
· Marketplace payments and WhatsApp/software subscription payments use separate financial flows and entitlements.
· Never provide or store UPI PIN, ATM PIN, payment PIN, CVV, banking passwords or similar payment authentication secrets in Suffle.
· Sellers do not connect their own payment gateway for Suffle marketplace customer payments.
· Failed, cancelled or expired payments must never be represented as successful payments or confirmed orders.
· Refunds and financial states must be based on verified payment-system records.
Related Suffle Policies
· Terms & Conditions
· Privacy Policy
· Data Security & Protection Policy
· Subscription Policy
· Refund & Cancellation Policy
· Commission & Seller Settlement Policy
· Custom & Personalised Products Policy
· Seller Terms / Seller Agreement
Regulatory / Drafting Reference
This Policy is intended to operate alongside applicable Indian payment, consumer-protection, data-protection, tax, accounting and information-technology requirements, and the applicable terms and technical requirements of Razorpay and other payment infrastructure involved in a transaction.
