Snapmint

Snapmint is a Mumbai fintech selling buy now pay later at checkout: a shopper splits a purchase into 3, 6, 9 or 12 monthly instalments without a credit card, using a debit card or UPI, and the merchant is paid in full on a T plus 2 cycle. It is catalogued here among shipping carriers and logistics tools, which is wrong: Snapmint carries nothing and ships nothing. It is a payment method, and the objects it touches are orders.payment_method and settlements. Snapmint publishes no developer documentation of its own, though a merchant API clearly exists. The one path that is properly documented is the indirect one, through Razorpay Optimizer, and that is set out in full below.

At a glance

What it is

An Indian BNPL and cardless EMI provider, headquartered in Vidyavihar West, Mumbai, with consumer apps on Google Play and the App Store and a merchant arm at snapmintbusiness.com. The consumer proposition is "Easy EMI shopping without a credit card": pay in 3, 6, 9 or 12 month instalments, marketed at zero percent interest on qualifying offers, with eligibility approved digitally against a debit card or UPI rather than a credit card.

Merchant categories named on the consumer site are electronics, mobiles, appliances, kitchen, health and wellness, fashion and sports, which is the standard high average-order-value BNPL mix.

Razorpay's own description, which is a useful independent framing, is that Snapmint "offers a credit line, often linked to your customers' debit card or UPI", with instant digital approval and minimal paperwork, and that the merchant "receives the full transaction amount from Snapmint" while "customers then pay Snapmint the total order amount in EMIs, along with any applicable interest".

Commercially the important number is the settlement cycle. Snapmint's business site states: "Snapmint follows a T+2 cycle to settle full payments. We settle the full payment" regardless of the tenure the shopper chooses. Read 2026-09-22. No MDR, discount rate or fee schedule is published anywhere, which is normal for this sector and means the commercials are negotiated.

API access

Snapmint publishes nothing technical. The infrastructure, checked on 2026-09-22:

So a merchant API exists and is entirely private. There is no WordPress.org plugin for Snapmint, so its WooCommerce and Magento integrations are distributed directly rather than through public plugin repositories, and no Snapmint app is listed in the Shopify App Store under that name.

Snapmint's business site claims "50+ seamless integrations" and names these:

That last line is the only first-party acknowledgement that a direct API exists, and it says nothing more.

The documented route: Razorpay Optimizer

Razorpay publishes Snapmint's integration in its own documentation, which makes this the only path an engineer can implement today from public material.

On Razorpay's standard checkout no work is needed at all: Razorpay's documentation states that "No additional integration is required to show Snapmint as a Cardless EMI service provider on your Standard Checkout integration." The shopper enters a phone number, chooses EMI, chooses "Cardless and Others", verifies an OTP to check eligibility, selects Snapmint, picks a tenure and pays.

On Razorpay's custom checkout, Snapmint is a provider value on the cardless EMI method:

razorpay.createPayment({
  amount: 5000,
  email: 'gaurav.kumar@example.com',
  contact: '9000090000',
  order_id: 'order_9A33XWu170gUtm',
  method: 'cardless_emi',
  provider: 'snapmint'
});

snapmint is one of the documented values of provider, alongside hdfc, icic, idfb, kkbk, zestmoney, earlysalary, walnut369 and shopse. Cardless EMI is an on-demand feature on Razorpay and must be enabled on the account first.

Two constraints matter. Razorpay states that Snapmint "is available only with Optimizer", its payment routing product, so a plain Razorpay account is not enough. And onboarding Snapmint inside Optimizer explicitly requires the merchant to supply its own Snapmint credentials: the documented steps are to open Optimizer, add a provider, pick Snapmint under "Cardless EMI only", enter provider details and then "Add your Snapmint Production API Details". That confirms a per-merchant Snapmint credential pair exists, even though its format is unpublished.

If Razorpay is already in the stack, this is the route. See /connectors/razorpay for that interface, which is fully documented on Razorpay's side.

Authentication

Not published by Snapmint. The only evidence of the credential model is Razorpay's onboarding step asking for "Snapmint Production API Details", which implies a key and secret issued per merchant, with a production and presumably a test variant. No token endpoint, header name, signature scheme, lifetime or scope model is documented anywhere, and api.snapmint.com exposes nothing unauthenticated beyond its welcome page.

No code sample can be written honestly for a direct integration. For the Razorpay route, authentication is Razorpay's, using the merchant's Razorpay key id and secret, and it is fully documented.

Objects we can read

Snapmint is a payment provider. Most unified objects simply do not exist here.

Orders

Only as payment transactions. A Snapmint transaction carries an amount, a merchant order reference, a shopper phone number, an approval outcome, a tenure and a status. Snapmint is not the system of record for the commercial order, which lives in the merchant's store or marketplace. Read orders from the sales channel connector and use Snapmint to populate the payment fields.

Where Razorpay fronts the transaction, the order and payment objects are Razorpay's and are documented, which is a much better read surface than anything Snapmint offers.

Order items

Not exposed. BNPL underwriting looks at the cart value and the shopper, not the line items, though some providers receive an item list for risk scoring. Nothing published says whether Snapmint does.

Products and listings

None. Snapmint holds no catalogue.

Inventory

None.

Shipments and tracking

None. This is the reason the catalogue entry is miscategorised. Snapmint neither ships nor tracks anything.

Returns and cancellations

Not exposed as an object, but the behaviour matters: when a BNPL-funded order is refunded, the instalment plan must be unwound. Nothing in public material describes how a merchant initiates a refund against a Snapmint transaction, what happens to instalments already collected, or how the reversal appears in settlement. That is a first-order operational question and it is undocumented.

Payments and settlements

The object that matters. Snapmint pays the merchant the full transaction amount on a T plus 2 cycle irrespective of the shopper's tenure, so from the merchant's side a BNPL sale settles like a normal prepaid sale two business days later. Snapmint then carries the credit risk and collects the instalments.

No settlement report format, endpoint, file drop or reconciliation key is published. A merchant dashboard exists at dashboard.snapmint.com, behind login, and is presumably where statements live. For the Razorpay route, settlement is Razorpay's and is documented.

Customers

Snapmint holds a great deal: phone number, identity, debit card or UPI linkage, and a credit decision. All PII, and some of it financial. None of it is exposed to the merchant beyond what the checkout returns. Treat Snapmint as an independent controller of shopper credit data, not a processor, and get that reflected in the contract.

Locations

Not applicable.

Writing back: listings, price and stock

Not applicable. This entry is filed as a carrier and it is not one; it is also not a sales channel. Snapmint has no listings, no prices and no stock to write.

The write-shaped operations that do exist are payment operations: create a payment against a merchant order, capture or confirm it, and refund it. On the Razorpay route those are Razorpay's documented payment and refund APIs with provider: 'snapmint' on the cardless EMI method. On a direct Snapmint integration they exist behind api.snapmint.com and are undocumented.

The one merchant-facing surface adjacent to a catalogue is the EMI eligibility and tenure widget shown on a product page, which needs the product price to compute instalments. That is a read of the merchant's price by Snapmint's script, not a write by anyone.

Webhooks and notifications

Snapmint publishes no webhook documentation. Payment status almost certainly reaches a merchant one of two ways: a redirect and callback in the checkout flow, or an event from the gateway that fronts the transaction.

On the Razorpay route, use Razorpay's documented webhooks: payment.captured, payment.failed, refund.processed and the settlement events, all signed with the Razorpay webhook secret. That is the only push mechanism available here with a documented signature, and it is the right one to build on.

For a direct integration, ask Snapmint for: the event catalogue, the request body, the signature header and algorithm, the retry policy, and whether instalment-level events, a missed instalment for example, are visible to the merchant at all. That last one usually is not, and merchants are often surprised.

Rate limits and pagination

Not published. No quota headers appear on any unauthenticated response from api.snapmint.com. On the Razorpay route, Razorpay's published limits apply.

Mapping to the unified model

Only orders.payment_method and settlements have counterparts. The rest is listed to record explicitly that it does not apply.

Gaps and open questions

• The direct merchant API is entirely undocumented: no endpoints, no authentication, no request or response shapes, no error codes, no limits.
• No sandbox exists at any published hostname, so direct integration testing appears to be against production.
• Refund behaviour against a live instalment plan is undocumented and is the highest-risk unknown for any merchant.
• The MDR or discount rate is not published, so the true settled amount cannot be modelled.
• Whether a merchant receives instalment-level or delinquency events is unknown. Assume not.
• No settlement report format or reconciliation key is published.
• The fifty plus integrations claim names nine platforms. The rest are unlisted, so whether a given checkout stack is supported has to be asked.
• Snapmint has no WordPress.org plugin and no Shopify App Store listing under its own name, so its platform integrations are distributed privately and their update path is opaque.
• Recommendation: if BNPL coverage is needed, integrate through Razorpay Optimizer or another gateway that already carries Snapmint, rather than directly. The documentation, the signature verification and the settlement reporting all exist on the gateway side and none of it exists on Snapmint's.

Sources

• Snapmint consumer site, read 2026-09-22, for the product, tenures, categories and Mumbai location
• Snapmint for merchants, which describes the merchant proposition and no technical detail
• Snapmint for Business, for the 50 plus integrations claim, the nine named platforms, the API integration option and the T plus 2 settlement statement
• Razorpay documentation, About Snapmint Cardless EMI, for the payment flow, the Optimizer-only constraint and the statement that no extra work is needed on standard checkout
• Razorpay documentation, Snapmint on Optimizer, for the onboarding steps and the requirement to supply Snapmint production API details
• Razorpay documentation, custom checkout payment methods, for the method: cardless_emi and provider: snapmint request shape and the full provider list
• Live HTTP checks on https://api.snapmint.com/ and its /docs, /api-docs, /swagger, /openapi.json, /health, /v1 and /api/v1 paths, and DNS checks across the Snapmint hostnames listed above, run 2026-09-22
• WordPress.org plugin API queries for a Snapmint plugin, which return no results, and a Shopify App Store search returning no Snapmint listing
• GitHub's published DMCA notice archive, entry dated 2026-08-19 filed on Snapmint's behalf, noted above as a caution against third-party repositories