Secure Razorpay payment automation architecture for multi-tenant SaaS using n8n

Help me Build my Workflow
1

Hello n8n community,

I am building a multi-tenant automation platform for boutique businesses.

My stack:

  • FlutterFlow (frontend)
  • Supabase (database/backend)
  • n8n (automation layer)
  • Razorpay (payment gateway)

My requirement:

Each boutique owner will have their own Razorpay account.

Customer flow:

Customer places order
↓
Clicks Pay button
↓
Completes payment through Razorpay
↓
Payment gets verified
↓
Customer receives WhatsApp/SMS order confirmation

My main concern is security.

I do not want clients to send their Razorpay Key ID and Secret Key through WhatsApp, email, or manually share credentials.

I want to follow a professional SaaS approach.

My questions:

  1. Can n8n receive Razorpay webhooks securely after payment completion and trigger confirmation messages?

  2. Is it recommended to keep Razorpay payment creation/verification outside n8n (for example using Supabase Edge Functions or another backend) and use n8n only for automation?

  3. For a multi-tenant system, should I use one n8n instance with separate business_id workflows/data isolation, or separate n8n instances for each client?

  4. What is the best practice for handling third-party API credentials securely in n8n when building automations for multiple clients?

I want to build a secure and scalable system similar to SaaS platforms.

Any guidance from people who have built similar systems would be highly appreciated.

Thank you.

2

Yes, n8n can safely handle the post-payment automation, but I would keep the payment trust boundary outside the workflow:

  • FlutterFlow should never receive or store a Razorpay secret. During merchant onboarding, use Razorpay Partner/OAuth if your account supports it; otherwise collect credentials only through an authenticated backend and store them encrypted in a vault, keyed by tenant.
  • Create the Razorpay order and perform payment verification in a Supabase Edge Function/backend. For webhooks, preserve the raw request body and verify X-Razorpay-Signature with the tenant’s webhook secret before parsing or triggering anything.
  • Resolve the tenant from a non-secret identifier (for example a dedicated endpoint ID or Razorpay account ID), then enforce replay protection/idempotency with a unique event ID or payment/order ID.
  • Only after verification, send a minimal internal event such as {business_id, order_id, payment_id, status} to n8n using a signed internal token. n8n can then handle WhatsApp/SMS and operational follow-up.

A single n8n instance is reasonable initially if every database query is scoped by business_id, credentials are isolated, execution data does not expose secrets, and one parameterized workflow is used instead of copied per-client workflows. Use separate instances only for customers needing hard regulatory or infrastructure isolation.

5

Byte_Nova and Cloudrocket have the credential and verification side right. The thing worth settling before you build, that hasn’t come up yet: with each boutique on their own Razorpay account, the customer’s payment lands in the boutique’s account, not yours. There’s no native split, so where does your platform commission come from?

That question only has a few real answers, and they’re fund-flow topologies, not settings you flip later:

Keep independent per-boutique accounts. The money sits with them, and you invoice or reconcile commission after settlement. Cleanest for their autonomy, most work for you.

Move to a platform-controlled split. This is where “each boutique has their own account” quietly stops being true. With Route, the full charge captures into your account first and boutiques become linked sub-accounts, not independent merchants. An aggregator/sub-merchant setup is a different shape, but it also puts you in the fund path. Either way the boutique becomes a sub-account under you — that’s a different account topology, not a config toggle, and it’s the migration people assume they can bolt on afterward.

Two things to design now regardless of which you pick:

Settlement reconciliation. Each account settles on Razorpay’s own schedule, net of fees, refunds, and adjustments. If your commission is computed from the order amount at capture, it drifts from what actually settled. You want a per-tenant match of settlement reports to orders, or the books diverge without anyone noticing.

Refunds and disputes. Same idempotency keying they already flagged, but now on an event that lands days later from the tenant’s account. The trap isn’t the double-refund — it’s the dispute silently leaving the commission you already counted on the books. Whatever rolls back the payment has to roll back the commission with it.

And keep card data out of FlutterFlow and n8n entirely — hosted checkout or tokens, so the PAN never touches your stack. The moment it does you inherit full PCI-DSS scope.

Which of these fund-flow models have you actually settled on? That one choice decides who owns settlement, refunds, and PCI — everything downstream hangs off it.

— Priyanshu Kumar