Ellipse Gradient for Header

Razorpay Integration Guide

Connect Razorpay payments, orders, refunds, invoices, and subscriptions with enterprise systems through REST APIs, selected webhooks, and Martini workflows.

Razorpay integration options at a glance

Razorpay's primary integration mechanism is its REST API, which supports Orders, Payments, Refunds, Customers, Invoices, Payment Links, Subscriptions, Settlements, and other resources. Razorpay also supports webhooks for selected payment, order, refund, invoice, payment-link, subscription, settlement, and dispute events. Webhook signatures should be verified, and financially important events should trigger retrieval of the authoritative Razorpay resource. Standard API access uses HTTP Basic Authentication with a key_id and key_secret, while webhook requests use a configured signing secret. Martini can orchestrate API calls, webhook workflows, mappings, validation, reconciliation, retries, and downstream updates.

Integration pointSupported by Razorpay?Common use casesHow Martini supports it
REST APIsYesCreate and retrieve Orders, Payments, Refunds, Customers, Invoices, Payment Links, Subscriptions, and Settlements. REST APIs are Razorpay's primary programmable integration mechanism.Martini can consume Razorpay REST endpoints from workflows, map JSON payloads, apply business rules, and expose an internal API façade for calling applications.
Webhooks / outbound callbacksYesReceive selected payment, order, refund, invoice, payment-link, subscription, settlement, and dispute notifications. Coverage is resource- and product-specific.Martini can receive Razorpay webhook requests, verify HMAC-SHA256 signatures, deduplicate events, retrieve current resources, and route outcomes to downstream systems.
AuthenticationYesStandard API calls use HTTP Basic Authentication with key_id as the username and key_secret as the password. Webhooks use a configured webhook secret for signature verification.Martini can store credentials and webhook secrets in protected environment configuration or secrets and apply them to API and webhook workflows.
Bulk / async / batch APIsLimitedSome Razorpay products document asynchronous or reporting capabilities, but a universal bulk API for all resources was not confirmed.Martini can orchestrate product-specific asynchronous or reconciliation flows when the applicable Razorpay API is confirmed, with checkpoints and controlled retries.
Scheduled synchronizationYesScheduled reconciliation can compare Razorpay Payments, Refunds, Orders, and settlement-related data with downstream finance or commerce systems.Martini can schedule workflows, paginate through applicable resources, store synchronization checkpoints, and reconcile late or missed webhook events.
File / attachment APIsNot confirmedProduct-specific reporting or document capabilities may exist, but a general-purpose file or attachment API was not confirmed in the core documentation.Martini should use confirmed Razorpay APIs or documented reports rather than assuming arbitrary file exchange capabilities.
GraphQL APIsNot confirmedNo official Razorpay GraphQL API was identified in the supplied documentation.Martini can consume GraphQL generally, but Razorpay integrations should use the confirmed REST API instead.
SOAP APIsNot confirmedNo official Razorpay SOAP API was identified.Martini can consume SOAP services generally, but SOAP should not be used as the assumed Razorpay integration method.

How Razorpay exposes data and business events

Razorpay REST APIs

Razorpay REST APIs provide the main programmable interface for creating and managing Orders, Payments, Refunds, Customers, Invoices, Payment Links, Subscriptions, Settlements, and related resources. Standard requests use HTTP Basic Authentication with the account key_id and key_secret.

Martini implementation pattern

Martini implementation pattern: a workflow or Martini API receives a business request, calls the relevant Razorpay endpoint, validates the response, transforms Razorpay JSON into a canonical model, and writes the result to the requesting or downstream application.

Implementation sequence

Receive a request from an internal application
Validate amount, currency, identifiers, and business rules
Call the applicable Razorpay REST endpoint
Map and normalize the Razorpay JSON response
Write the result to the target application
Store correlation identifiers and processing status

Razorpay Webhooks

Razorpay supports webhooks for selected resource and product events, including payment, order, refund, invoice, Payment Link, subscription, settlement, and dispute notifications where configured. Coverage is not universal for every API state change.

Martini implementation pattern

Martini implementation pattern: expose a webhook endpoint, verify the Razorpay signature using the configured webhook secret, treat the notification as a trigger, retrieve the related Razorpay resource for financially significant decisions, and process the result idempotently.

Implementation sequence

Receive the Razorpay webhook request
Verify the HMAC-SHA256 signature
Identify the event and external resource
Retrieve the current Razorpay resource when required
Check event or business-key duplication
Map the state to the downstream model and write the result

Scheduled Razorpay Reconciliation

Scheduled reconciliation is useful when webhook delivery is incomplete, delayed, or insufficient for finance controls. Razorpay resource-specific pagination and reporting behavior should be confirmed for each endpoint or product.

Martini implementation pattern

Martini implementation pattern: schedule a workflow to retrieve relevant Payments, Refunds, Orders, or settlement-related data, compare it with stored downstream state, and repair or flag discrepancies without duplicating successful writes.

Implementation sequence

Start the reconciliation workflow on a schedule
Load the last successful synchronization checkpoint
Retrieve applicable Razorpay resources page by page
Compare external identifiers and current states
Apply missing or corrective downstream updates
Persist the new checkpoint and reconciliation outcomes

Razorpay Asynchronous Processing

Razorpay documents asynchronous processing for some operations and products, but a general-purpose bulk API for all resources was not confirmed. Product-specific capabilities should be validated before implementation.

Martini implementation pattern

Martini implementation pattern: model confirmed asynchronous operations as long-running or checkpointed workflows, process completion signals or follow-up retrievals, and route unresolved outcomes to controlled retry or review paths.

Implementation sequence

Submit the confirmed asynchronous Razorpay operation
Store the request and correlation identifiers
Receive or poll for the operation outcome
Retrieve the resulting Razorpay resource
Apply mapping and business validation
Complete, retry, or escalate the workflow

Common Razorpay integration patterns

Pattern 1: Create orders and synchronize payment status

When to use this pattern

Use this pattern when a checkout, commerce, or internal application needs a Razorpay Order before payment and must receive a reliable payment outcome afterward. The webhook starts processing, while the API response provides the authoritative state for important financial decisions.

Integration direction
Commerce application
Martini
Razorpay
Example Mapping
Razorpay FieldCanonical FieldTarget Field
order.idexternalOrderIdcommerceOrder.razorpayOrderId
amountorderAmountMinorUnitscommerceOrder.paymentAmount
payment.statuspaymentStatuscommerceOrder.paymentStatus
Martini implementation pattern

A Martini API accepts the order request, validates amount, currency, and internal references, and calls Razorpay to create the Order. A webhook workflow verifies the signature, retrieves the related Payment or Order, applies lifecycle rules such as authorized versus captured, and updates the commerce application. Duplicate requests and transient API failures use correlation keys and bounded retries.

Martini capabilities used
  • APIs
  • workflows
  • API consumption
  • data mapping
  • business rules
  • error handling

Pattern 2: Synchronize payments and refunds to finance

When to use this pattern

Use this pattern when Razorpay payment and refund activity must be posted to NetSuite, SAP S/4HANA, Microsoft Dynamics 365, or Xero for receivables, cash application, credit memo, or reconciliation processes.

Integration direction
Razorpay
Martini
Finance application
Example Mapping
Razorpay FieldCanonical FieldTarget Field
payment.idexternalPaymentIdfinanceTransaction.externalReference
amountamountMinorUnitsfinanceTransaction.amount
refund.statusrefundStatusfinanceCreditMemo.status
Martini implementation pattern

Martini receives selected Razorpay notifications, retrieves authoritative Payments or Refunds, preserves integer minor-unit amounts, and maps them into the target finance model. Deterministic lookups prevent duplicate postings, while unmatched, partially refunded, or failed transactions are routed to exception handling. A scheduled workflow reconciles missed events and late updates.

Martini capabilities used
  • webhook consumption
  • scheduled workflows
  • data mapping
  • validation
  • business rules
  • retries
  • monitoring

Pattern 3: Automate invoices and Payment Links

When to use this pattern

Use this pattern when a CRM, ERP, or billing application needs to generate a hosted Razorpay payment request and receive completion or expiry updates against an Invoice or customer account.

Integration direction
Billing application
Martini
Razorpay
Example Mapping
Razorpay FieldCanonical FieldTarget Field
customer.idcustomerExternalIdrazorpayCustomer.id
invoice.amountinvoiceAmountMinorUnitsrazorpayInvoice.amount
short_urlhostedPaymentUrlbillingApplication.paymentUrl
Martini implementation pattern

A Martini workflow accepts customer and invoice details, creates or retrieves a Razorpay Customer and then creates an Invoice or Payment Link. It returns the hosted URL to the originating application, consumes selected Razorpay events, retrieves the current resource, and updates invoice status with validation and retry handling.

Martini capabilities used
  • API orchestration
  • workflows
  • data transformation
  • conditional routing
  • API exposure
  • error handling

Pattern 4: Monitor subscription payments

When to use this pattern

Use this pattern when recurring payment activity must update customer entitlements, CRM records, or finance systems and failed payments require notification, retry, or account-review decisions.

Integration direction
Razorpay
Martini
CRM or entitlement application
Example Mapping
Razorpay FieldCanonical FieldTarget Field
subscription.idsubscriptionExternalIdcustomerSubscription.externalReference
invoice.statusbillingStatusentitlement.billingStatus
payment.error_codepaymentFailureReasoncustomerAccount.reviewReason
Martini implementation pattern

Martini receives selected subscription-related events, retrieves the relevant Subscription, Payment, or Invoice, and applies business rules for active, failed, pending, or review states. It updates the CRM or entitlement application and routes transient failures through bounded retries while preserving a processing audit trail.

Martini capabilities used
  • event-driven workflows
  • API consumption
  • mapping
  • business rules
  • conditional routing
  • retry handling

Applications commonly integrated with Razorpay

Razorpay can be integrated with commerce, CRM, ERP, accounting, and operational applications when payment initiation, status synchronization, refunds, invoicing, or reconciliation must cross system boundaries. The exact flow depends on the deployed Razorpay product and the customer's application architecture.

Application Scenario Direction Martini Pattern
Shopify Synchronize payment outcomes, refunds, and order payment status for online purchases. Shopify → Martini → Razorpay Expose or consume the checkout flow through a Martini workflow, call Razorpay REST APIs for payment-related operations, receive selected Razorpay events, and update Shopify after retrieving and validating the authoritative payment or refund state.
Salesforce Associate Razorpay Orders, Payments, Refunds, or Payment Links with Salesforce Accounts, Contacts, Opportunities, or Cases. Salesforce → Martini → Razorpay Use a Martini API or workflow to accept payment requests from Salesforce, create the relevant Razorpay resource, and process Razorpay webhook notifications into Salesforce updates with validation and duplicate protection.
NetSuite Post customer payments, refunds, invoices, and settlement information for financial reconciliation. Razorpay → Martini → NetSuite Receive Razorpay events, retrieve Payments, Refunds, Invoices, or settlement data, map amounts and external identifiers to NetSuite financial objects, and route unmatched or failed transactions for review.
SAP S/4HANA Transfer payment, refund, and settlement information into finance processes and reconcile customer receivables. Razorpay → Martini → SAP S/4HANA Use event-driven workflows for timely updates and scheduled reconciliation for completeness, applying monetary-value validation, canonical mappings, idempotency checks, and retry handling before writing to SAP S/4HANA.
Microsoft Dynamics 365 Synchronize payment activity with invoices, sales orders, and customer accounts. Microsoft Dynamics 365 → Martini → Razorpay Accept payment initiation requests from Dynamics 365, call Razorpay REST endpoints, then consume selected Razorpay notifications and update Dynamics 365 only after current resource state has been confirmed.
ServiceNow Create operational or support cases for failed payments, refunds, disputes, and reconciliation exceptions. Razorpay → Martini → ServiceNow Route selected Razorpay payment and refund outcomes through Martini business rules, enrich exceptions with current Razorpay data, and create or update ServiceNow cases with correlation identifiers.
Xero Post or reconcile payments, refunds, fees, invoices, and customer account activity. Razorpay → Martini → Xero Map Razorpay financial objects to Xero transaction models, preserve smallest-currency-unit values during transformation, use idempotent writes, and run scheduled reconciliation for missed or late events.
WooCommerce Synchronize checkout payment results, order status, and refunds for online stores. WooCommerce → Martini → Razorpay Use Martini to coordinate payment initiation and Razorpay API calls, consume selected Razorpay events, retrieve the current Payment or Refund, and update WooCommerce with controlled retries.

How to build a Razorpay integration in Martini

Objective

Establish separate Razorpay test and live configurations and protect API and webhook credentials.

Instructions in Martini

  • Configure HTTP Basic Authentication with Razorpay key_id and key_secret
  • Store credentials and webhook secrets in Martini secrets or protected environment configuration
  • Keep test and live credentials separate
  • Avoid writing authorization headers or secrets to logs

Objective

Select an API-led, webhook-driven, or scheduled trigger based on the business process and required completeness.

Instructions in Martini

  • Use a Martini API or workflow for order, invoice, Payment Link, or refund initiation
  • Use a webhook endpoint for selected Razorpay event notifications
  • Use a scheduler for reconciliation and recovery of missed events
  • Document which Razorpay resources and events are in scope

Objective

Obtain the Razorpay data needed to make a reliable business decision.

Instructions in Martini

  • Verify webhook signatures before processing payloads
  • Treat webhook notifications as triggers rather than universal proof of final state
  • Retrieve the related Order, Payment, Refund, Invoice, or Subscription when financially significant
  • Handle resource-specific pagination and response structures

Objective

Coordinate API calls, validation, enrichment, downstream writes, and exception paths in a maintainable Martini workflow.

Instructions in Martini

  • Correlate internal references with Razorpay identifiers
  • Route payment, refund, invoice, and reconciliation outcomes conditionally
  • Separate transient transport retries from business retries
  • Persist checkpoints and processing outcomes

Objective

Convert Razorpay JSON and payment lifecycle states into canonical and target-system models.

Instructions in Martini

  • Map external identifiers and statuses to canonical fields
  • Preserve monetary amounts in smallest currency units where possible
  • Validate currency, amount, and required references
  • Treat optional product-specific fields as optional

Objective

Enforce idempotency, lifecycle, security, and exception rules before committing downstream changes.

Instructions in Martini

  • Prevent duplicate Order, Payment, or Refund effects
  • Distinguish authorization, capture, failure, pending, full refund, and partial refund states
  • Route unmatched or invalid transactions for review
  • Avoid processing raw payment-card data through Martini where it is not required

Common Razorpay data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
OrdersRepresent payment orders created before a customer completes payment.Shopify, WooCommerce, Salesforce, NetSuite, SAP S/4HANAMartini creates or retrieves Orders through REST workflows, validates amount and currency, stores the Razorpay identifier, and correlates later Payment events.
PaymentsRepresent payment attempts and successful or failed transactions.NetSuite, SAP S/4HANA, Microsoft Dynamics 365, Salesforce, XeroMartini receives selected notifications, retrieves the current Payment, maps lifecycle status and monetary values, and applies idempotent downstream updates.
RefundsRepresent money returned against captured Payments.NetSuite, Xero, Shopify, WooCommerce, SalesforceMartini retrieves or creates Refunds, prevents duplicate processing, maps full or partial refund amounts, and routes unmatched refunds for review.
CustomersStore customer information associated with payments and payment instruments.Salesforce, Microsoft Dynamics 365, Shopify, XeroMartini maps customer identifiers and contact data, applies validation rules, and creates or updates downstream customer profiles where appropriate.
InvoicesRepresent invoices issued through Razorpay.NetSuite, SAP S/4HANA, Microsoft Dynamics 365, XeroMartini retrieves invoice state, maps amounts and payment status, and synchronizes invoice updates through event-driven and scheduled workflows.
Payment LinksRepresent hosted payment requests shared with customers.Salesforce, NetSuite, Microsoft Dynamics 365, ShopifyMartini creates Payment Links from upstream customer or billing data, returns the hosted URL, and processes selected completion or expiry events.

Authentication and security considerations

API credentials

Standard Razorpay API access uses HTTP Basic Authentication with the Razorpay key_id as the username and key_secret as the password. Test and live credentials should be configured separately.

Webhook verification

Razorpay webhook signatures should be verified with the configured webhook secret using the documented HMAC-SHA256 verification approach before a workflow processes the event.

  • Store key_id, key_secret, and webhook secrets in Martini secrets or protected environment configuration.
  • Restrict access to live credentials and apply least-privilege controls where applicable.
  • Do not log secrets, authorization headers, or unnecessary payment-sensitive data.
  • Prefer hosted or tokenized payment flows rather than passing raw card data through Martini.

Operational considerations for Razorpay integrations

Reliability and reconciliation

Webhook delivery is selected and product-specific rather than universal. Use webhooks for timely processing and scheduled API reconciliation for completeness, late events, and recovery.

Idempotency and lifecycle

  • Store Razorpay Order, Payment, Refund, Invoice, and Subscription identifiers.
  • Prevent duplicate effects when webhook deliveries or transport requests are retried.
  • Distinguish authorization, capture, failure, pending, full refund, and partial refund states.
  • Retrieve the authoritative resource before financially significant decisions.

API behavior and schema

  • Check applicable Razorpay limits and use bounded backoff for transient failures or throttling.
  • Confirm pagination behavior for each resource rather than assuming all endpoints are identical.
  • Preserve monetary values in the smallest currency unit and validate currency consistency.
  • Treat product-specific and optional fields as optional and test mappings when schemas or event payloads change.

Why use Martini instead of scripts or point-to-point integrations?

Centralized orchestration

Martini coordinates Razorpay API calls, webhook processing, scheduled reconciliation, downstream writes, and exception paths in reusable workflows instead of scattering payment logic across scripts and point-to-point integrations.

Controlled transformation

Martini maps Razorpay Orders, Payments, Refunds, Invoices, Payment Links, Customers, and Subscriptions into canonical and target-system models while applying amount, currency, lifecycle, and business-rule validation.

Maintainable operations

  • Expose a controlled API façade so internal applications do not each implement Razorpay details.
  • Centralize secrets, signature verification, retries, idempotency, and reconciliation checkpoints.
  • Support event-driven and scheduled workflows in the same integration design.
  • Provide structured error handling, logging, monitoring, and reusable integration assets as requirements evolve.

Frequently asked questions

How can Razorpay be integrated with enterprise systems?

Razorpay can be integrated primarily through its REST APIs for Orders, Payments, Refunds, Customers, Invoices, Payment Links, Subscriptions, and other resources. Selected resource and product events can be received through Razorpay webhooks, while scheduled API-based reconciliation can address missed or delayed notifications.

Can Martini integrate with Razorpay?

Yes. Martini can integrate with Razorpay by consuming its REST APIs, receiving selected webhook notifications, verifying webhook signatures, mapping Razorpay JSON, orchestrating workflows, and synchronizing payment data with downstream applications.

Do I need a connector to integrate Razorpay with Martini?

No. A dedicated Razorpay connector is not required. Martini can use Razorpay's documented REST APIs, webhook notifications, HTTP Basic Authentication, webhook signature verification, and applicable product-specific endpoints.

Is there any extra Lonti cost to integrate Razorpay with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Razorpay. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Razorpay, cloud infrastructure providers, or other third-party systems depending on subscriptions, usage, and deployment model.

Which Razorpay integration methods should a new implementation use?

Use Razorpay REST APIs as the primary programmable interface and selected webhooks for timely event notification. Use scheduled reconciliation for completeness and rely on product-specific asynchronous or reporting capabilities only after confirming their applicability to the account and resource.

Are Razorpay events and webhooks available?

Yes, Razorpay supports webhooks for selected payment, order, refund, invoice, Payment Link, subscription, settlement, and dispute events where configured. Coverage is resource- and product-specific, so Martini should verify signatures and retrieve the current resource for important financial decisions.

How should Razorpay data synchronization and reconciliation work?

Use webhooks for near-real-time processing, then run scheduled workflows that retrieve and compare Payments, Refunds, Orders, and settlement-related data with the downstream system. Store Razorpay identifiers, checkpoints, and processing outcomes to support audit, retries, and duplicate prevention.

Can Martini expose an API façade for Razorpay?

Yes. Martini can expose a controlled API that accepts internal order, invoice, Payment Link, or refund requests, applies validation and business rules, calls Razorpay REST APIs, and returns a canonical response without requiring each internal application to implement Razorpay details directly.