Sonic does not process card payments itself. Stripe and Razorpay do — Sonic adds pay-now links to invoices, listens for payment events, and marks invoices paid when the processor confirms capture.
That split keeps payment relationships where customers already have them while closing the AR loop inside contract-to-cash.
What you get
| Capability | Stripe | Razorpay |
|---|---|---|
| Hosted payment page | Yes | Yes (UPI, card, netbanking, wallet) |
| Invoice email link | Yes | Yes |
| Auto mark paid | Via webhook | Via webhook |
| Customer id stored | Stripe customer on Sonic customer | Razorpay linkage |
| Refunds from credit flow | Supported path | Supported path |
Default currency and enabled methods follow your processor account configuration — Sonic does not override Razorpay method visibility.
The step that gets skipped, and what it costs
Connecting a processor account and setting a default currency are the parts everyone remembers. The webhook endpoint registration in the processor's own dashboard is the part that gets skipped — and skipping it doesn't produce an error message, it produces invoices that stay open while the money has already arrived, because Sonic never heard about the payment. It's worth running one full test end to end — draft an invoice, pay it with test keys, confirm it flips to paid and collections stops chasing it — before trusting the integration on a real customer's invoice. Live keys in a sandbox environment charge real cards; keep test and production credentials in the environments they belong to.
What the customer sees, and what happens after
From the customer's side, this is simple: an invoice arrives with a pay-now link, they pay on the processor's hosted page, and that's the last they think about it. What happens next is entirely on Sonic's side — the processor notifies Sonic of the payment, the invoice flips to paid, and the dunning sequence for that invoice stops on its own. The payout itself, the actual money landing in your bank account, happens later and separately — which is why bank reconciliation still matters even for card payments.
Customer-facing invoice numbers use public invoice number — never raw internal ids with decorative prefixes.
Payouts vs invoice totals
Processor settlements arrive:
- Net of fees
- Batched across many charges
- Sometimes delayed vs charge date
Bank reconciliation matches payout lines to invoices with variance for fees. Do not expect deposit amount == invoice total.
GST details on Sonic invoices and Razorpay receipts should agree for Indian customers reclaiming input credit — mismatches block their compliance workflow.
What Sonic does not do
- Store PAN/card data as a processor replacement
- Dispute chargebacks inside Sonic as a full payments ops desk
- Replace treasury cash forecasting on settlement timing
Watch out for
- Webhook misconfiguration is the #1 "paid in bank, open in Sonic" bug.
- Mark paid manually still valid for wires — links are not the only path.
- Partial processor captures follow processor rules; AR may need partial match in bank rec.
- Freight and subscription invoices both support links — bill-to still shipper vs customer by workspace.
- Test in browser, not raw curl — some processor anti-bot blocks scripted posts.