Linking Razorpay as a source
This source is currently in alpha. The interface and available tables may change.
The Razorpay connector syncs your payments data – payments, orders, refunds, settlements, subscriptions, and more – into PostHog, so you can analyze revenue and payment activity alongside your product data.
Prerequisites
You need a Razorpay account and an API key pair (key ID and key secret). Razorpay issues separate key pairs for test mode (rzp_test_) and live mode (rzp_live_), so use a live-mode key to sync production data.
Adding a data source
- In PostHog, go to the Sources tab of the data pipeline section.
- Click + New source and click Link next to this source.
- Enter your credentials (see Configuration below) and click Next.
- Select the tables you want to sync, choose a sync method and frequency, then click Import.
Once the syncs are complete, you can start querying this data in PostHog.
When linking Razorpay, you'll need:
- Key ID and Key secret – in your Razorpay Dashboard, go to Account & Settings > API keys, then generate or regenerate a key. Copy both the key ID and the key secret (the secret is only shown once, at generation time).
Sync modes
Each table can be synced in one of several modes, depending on what the source supports:
- Webhook (when available) – the source pushes changes to PostHog in real time. Fastest freshness, lowest ongoing cost, and the only mode that reliably captures updates and deletes.
- Incremental – only new or updated rows are synced on each run, using a cursor field (such as an
updated_attimestamp). Cheaper than a full refresh, but deletes aren't captured. - Append only – new rows are appended using a cursor field; existing rows are never updated. Ideal for immutable, append-only tables like event logs.
- Full refresh – the whole table is reloaded on every sync. Use it when a table has no reliable cursor or when you need deletions reflected.
See sync methods for a full explanation of how each mode works and how to choose between them.
Razorpay's API filters on creation time only, so incremental syncs pick up newly created records plus a short trailing window of recent ones. Status changes on older records (for example, a payment refunded weeks after it was created) are only captured by a full refresh, so consider an occasional full refresh on mutable tables like payments and settlements. Tables without a creation-time filter (disputes, invoices, and virtual accounts) sync as full refresh only.
Configuration
| Option | Type | Required |
|---|---|---|
Key ID | text | Yes |
Key secret | password | Yes |
Supported tables
| Table | Description | Sync method | Incremental field | Primary key |
|---|---|---|---|---|
Customers | A customer of your business, identified by name, email, and contact number, that payments and orders can be associated with. | Incremental, Full refresh | created_at | — |
Disputes | A chargeback or dispute raised against a payment, including its phase, status, and the evidence submitted. | Full refresh | — | — |
Invoices | An invoice issued to a customer, carrying line items, amounts, payment status, and the linked order and payment. | Full refresh | — | — |
Items | A reusable item (product or service) with a name, price, and currency that can be added to invoices and subscriptions. | Incremental, Full refresh | created_at | — |
Orders | An order created to bind payments to a purchase intent; a payment is only considered complete against its order. | Incremental, Full refresh | created_at | — |
Payments | A payment made by a customer, covering every payment method (card, UPI, netbanking, wallet) and its full lifecycle status. | Incremental, Full refresh | created_at | — |
Plans | A billing plan defining the amount and billing cycle used to create subscriptions. | Incremental, Full refresh | created_at | — |
Refunds | A full or partial refund issued against a payment, with its processing status and speed. | Incremental, Full refresh | created_at | — |
Settlements | A settlement of captured payments transferred to your bank account, with fees, tax, and the bank UTR reference. | Incremental, Full refresh | created_at | — |
Subscriptions | A recurring billing relationship between a customer and a plan, with its cycle counts and lifecycle status. | Incremental, Full refresh | created_at | — |
VirtualAccounts | A Smart Collect virtual account (bank account number, VPA, or QR code) created to receive payments from a customer. | Full refresh | — | — |
Troubleshooting
If your sync is failing or data looks wrong, see the Data warehouse troubleshooting guide. If that doesn't help, contact support – we're happy to help.