Payment Gateway Integration (Razorpay/Stripe) for Websites

A checkout that opens and shows “Payment successful” is not yet a reliable payment integration. The business also needs a trusted order amount, server-side verification, duplicate-event protection, refunds, settlement reconciliation, customer communication, and a recovery path when any step fails.

This guide explains payment gateway integration for websites using Razorpay or Stripe as practical examples. It is for ecommerce stores, booking platforms, service businesses, course sellers, and SaaS teams that need a production checkout rather than a payment-button demo.

Quick Answer

The safe architecture is:

1. your server calculates the payable amount;
2. your server creates the provider order, payment intent, or checkout session;
3. the browser opens the provider checkout;
4. the return page shows a pending or confirmed status for user experience;
5. a signed server-to-server webhook confirms the authoritative payment event;
6. your database applies the result exactly once;
7. fulfilment, invoice, WhatsApp, or email actions run from the committed internal payment state.

Never let the frontend alone decide that an order is paid.

Razorpay or Stripe: Choose for the Business Context

Provider selection should follow the merchant account, customer geography, currency, payment methods, subscription requirements, payout operations, support, and total integration needs.

Do not pick a provider from a logo comparison. Open the required merchant account, verify eligibility, and confirm current official pricing and supported features before estimating development.

Core Checkout Architecture

Trusted Product and Price

The browser may send product IDs, quantities, coupon codes, or booking choices. The server must load the valid price, recalculate tax or fees according to the approved business rules, validate inventory or availability, and produce the final amount.

If the browser sends ₹1 for a ₹10,000 order, the server should reject or ignore the amount.

Internal Order First

Create an internal order before opening checkout. Give it:

• stable order ID;
• customer or guest reference;
• item snapshot;
• amount and currency;
• payment_pending status;
• expiry or reservation deadline;
• audit timestamps.

Then create the provider object and save its ID against the internal order.

Hosted or Embedded Checkout

Use the provider's supported checkout flow. Avoid collecting raw card details unless the business has a specific, reviewed requirement and the compliance capability to handle it.

The browser can receive a public checkout identifier. Secret API credentials remain on the server.

Browser Callback Versus Webhook

These two mechanisms serve different purposes.

Browser callback or return URL

• returns the customer to the website;
• can display an order reference;
• may query the server for current status;
• can show “we are confirming your payment”;
• is not reliable enough for final fulfilment.

Webhook

• travels server to server;
• includes a provider signature;
• can arrive even if the customer closes the browser;
• may be retried;
• should drive the authoritative internal state.

Razorpay's webhook documentation and Stripe's webhook documentation both describe signature verification and event delivery considerations. Follow the exact provider instructions, including use of the raw request body where required.

Payment State Machine

A single paid boolean hides operational detail. Use explicit internal states such as:

• created;
• checkout_opened;
• pending;
• authorised;
• captured or succeeded;
• failed;
• cancelled;
• partially_refunded;
• refunded;
• disputed.

Not every provider or payment method follows every state. Build an adapter that maps provider events into the states your business actually understands.

Keep the order state separate from payment state. A paid order may still be awaiting stock allocation, booking confirmation, manual review, or shipment.

Webhook Processing Pattern

Process each incoming event through a small, auditable sequence:

1. accept only the expected method and content type;
2. read the request body in the provider-required form;
3. verify the signature;
4. extract event ID, type, provider object ID, amount, and currency;
5. insert the event ID under a unique constraint;
6. load the internal order by the stored provider reference;
7. validate amount, currency, merchant account, and current state;
8. write the internal payment transition in a transaction;
9. enqueue downstream work;
10. return the provider-expected response quickly.

Store enough event metadata to investigate failures, but do not log secrets or unnecessary payment data.

Idempotency: One Payment, One Business Effect

Webhooks can be delivered more than once. Customers can double-click. Your server can time out after the provider accepted a request.

Use:

• idempotency key for server-side creation where supported;
• unique internal checkout/request key;
• unique provider event ID;
• unique provider payment ID;
• transactional status change;
• guard that prevents fulfilment from running twice;
• safe retry queue for downstream tasks.

“Exactly once” is achieved operationally by recording and deduplicating attempts, not by assuming the network delivers once.

Indian Business Example: Paid Booking

A diagnostic clinic sells a prepaid health package.

1. The user selects a package and appointment slot.
2. The server confirms the current package price and temporarily holds the slot.
3. An internal booking with payment_pending is created.
4. The provider checkout opens.
5. The return page shows that confirmation is in progress.
6. The signed webhook verifies the payment ID, amount, currency, and booking reference.
7. The booking becomes confirmed exactly once.
8. A receipt and WhatsApp confirmation are queued.
9. If confirmation fails, the payment remains visible in an exception queue for staff.

If the slot expires before payment verification, the system needs a defined recovery rule: restore the slot, offer a new slot, or trigger a refund review. That business decision must exist before launch.

Current VASUYASHII Product Boundary

The current VASUYASHII Business Suite scope includes invoice, payment, due, PDF, and secure WhatsApp-sharing workflows. Direct payment-gateway automation is not presented as a universal built-in feature; it is scoped separately when a business needs it. This published boundary is why the integration should connect through stable invoice and payment records instead of silently turning a checkout callback into an accounting result.

Refund and Cancellation Design

Refunds are a workflow, not just an API call.

Define:

• who may request and approve a refund;
• full versus partial refund;
• whether fulfilment must be cancelled first;
• how inventory or appointment capacity is restored;
• status shown to the customer;
• handling when the API accepts a refund but processing is pending;
• reconciliation with settlement;
• audit history and reason;
• treatment of fees according to provider rules.

Create a refund record before calling the provider and update it from authoritative responses or events. Avoid deleting the original payment.

Settlement and Reconciliation

Payment success means the customer's transaction succeeded. Settlement means funds are transferred according to the provider's process. Accounts teams need both.

A reconciliation view can compare:

• internal order amount;
• provider payment amount;
• refunds;
• fees and taxes reported by the provider;
• net settlement;
• settlement date and identifier;
• unmatched or disputed records.

Run a daily exception report. A payment should never disappear merely because the customer message or invoice-generation step failed.

Security Controls

• Keep secret keys in protected environment configuration.
• Separate test and production accounts and webhooks.
• Verify webhook signatures and reject failures.
• Use HTTPS everywhere.
• Calculate amount and currency on the server.
• Do not expose internal sequential IDs when a public opaque ID is safer.
• Restrict refund and reconciliation screens by role.
• Add CSRF protection where cookie-authenticated state changes require it.
• Mask logs and support screenshots.
• Alert on signature failures, amount mismatches, and repeated processing errors.
• Rotate compromised credentials and maintain a documented response procedure.

For a wider API and event architecture, see API integration services for CRM, ERP, WhatsApp and payments.

Implementation Roadmap

Phase 1: Business Rules

Map product, price, tax, availability, cancellation, refund, receipt, fulfilment, and settlement ownership.

Phase 2: Provider Sandbox

Create the merchant test account, credentials, callback URLs, webhook endpoint, and event mapping.

Phase 3: Internal State

Implement orders, transactions, event deduplication, logs, and exception queues before adding optional messaging.

Phase 4: Operational Tools

Add search, manual retry, refund approval, reconciliation, and customer support visibility.

Phase 5: Controlled Launch

Use a limited audience or product, monitor every event, reconcile daily, and expand only after the failure paths work.

Cost Drivers

Development cost depends on:

• fixed product checkout versus dynamic cart;
• coupons, taxes, shipping, inventory, or booking holds;
• guest checkout versus customer accounts;
• one-time versus subscription billing;
• partial payments and deposits;
• invoice and receipt generation;
• refund approval;
• WhatsApp/email automation;
• finance reconciliation;
• existing backend quality;
• provider onboarding and account requirements.

Provider transaction charges are separate from implementation and maintenance. Verify current commercial terms directly with the provider.

If the requirement is only invoice collection through hosted URLs, the simpler online payment links and invoice system guide may be a better starting point.

Launch Test Checklist

• [ ] browser cannot change the final amount;
• [ ] order exists before checkout opens;
• [ ] payment and order states are separate;
• [ ] valid webhook updates the correct order;
• [ ] invalid signature is rejected;
• [ ] duplicate event creates no duplicate fulfilment;
• [ ] wrong amount or currency enters an exception state;
• [ ] delayed event is handled;
• [ ] customer closing the browser does not lose the payment;
• [ ] failed payment releases reserved stock or slot correctly;
• [ ] full and partial refunds are tested;
• [ ] customer communication retries independently;
• [ ] finance can reconcile provider settlement;
• [ ] secrets are absent from frontend and logs;
• [ ] production monitoring and ownership are documented.

Common Mistakes

Trusting the Success Page

It can be skipped or manipulated. Use verified server events.

Creating Checkout Before an Internal Order

The payment then lacks a reliable business reference.

Running Fulfilment Inside a Slow Webhook

Commit the state and enqueue downstream work. Providers expect a timely response and may retry.

Ignoring Duplicate Events

This can create duplicate bookings, emails, invoices, or inventory movements.

Launching Without Reconciliation

Technical success does not guarantee that internal orders, provider transactions, refunds, and settlements agree.

FAQs

Which is better for an Indian website: Razorpay or Stripe?

It depends on business eligibility, customer geography, required methods, currency, recurring payments, support, and current provider availability. Validate the exact merchant use case.

Should payment verification happen in frontend or backend?

The backend should own final verification and state changes. The frontend can display the result returned by the backend.

What if the webhook is delayed?

Keep the order pending, let the status page poll or refresh safely, and process the event when it arrives. Add a reconciliation job for events that never arrive.

Can I send WhatsApp immediately after checkout?

Send it after the internal verified payment state commits. Use a queue so messaging failure does not affect payment recording.

Do I need a database for a payment button?

If the payment triggers an order, booking, invoice, subscription, or access grant, you need a durable internal record and audit trail.

Can the same integration support subscriptions?

Subscription billing introduces mandates, renewals, failed payments, plan changes, cancellation, proration, and entitlement rules. Treat it as a separate scoped workflow.

Related Reading

• Best payment gateway integration in India
• Webhook API integrations guide
• Online payment links and invoice system
• WhatsApp notifications after payment
• Ecommerce website cost in India

Conclusion

Reliable website payments come from state management and operations, not from the checkout popup alone. Keep prices trusted, create internal orders first, verify webhooks, deduplicate events, separate fulfilment, and reconcile settlements.

To scope a payment flow around your existing website, booking system, or business application, review integration services or contact VASUYASHII.