Aceite UPI e todos os cartões emitidos na Índia com mandatos de assinatura em conformidade com as normas do RBI. Entenda o atraso de processamento de 48 horas, os limites dos mandatos e o tratamento de webhooks.
A Índia tem uma infraestrutura de pagamentos única, dominada pelo UPI (mais de 60% das transações digitais) e por cartões emitidos na Índia (Visa, Mastercard, Rupay etc.). Dodo Payments oferece suporte a todos esses métodos com total conformidade com as normas do RBI para mandatos de assinatura.
Por que os métodos de pagamento da Índia são importantes
UPI Dominance
O UPI processa mais de 10 bilhões de transações por mês. Muitos clientes indianos não têm cartões internacionais.
Low Transaction Costs
O UPI tem taxas de transação próximas de zero. É excelente para transações de alto volume e menor valor.
Subscription Support
Ao contrário da maioria dos métodos de pagamento alternativos, o UPI e todos os cartões emitidos na Índia (Visa, Mastercard, Rupay etc.) oferecem suporte a pagamentos recorrentes por meio de mandatos do RBI.
*As assinaturas exigem mandatos em conformidade com as normas do RBI e regras especiais de processamento. O atraso de processamento de 48 horas se aplica a todos os cartões emitidos na Índia e ao UPI.
O valor registrado no banco do cliente é max(mandate_floor, billing_amount). Portanto, o piso funciona efetivamente como o teto de autorização exibido ao cliente sempre que a cobrança for inferior ao piso.Importante para alterações de plano: se um upgrade resultar em uma cobrança que exceda o limite do mandato existente, a cobrança falhará e o cliente deverá autorizar novamente.
O piso de mandato para e-mandates em INR pode ser configurado por meio do campo mandate_min_amount_inr_paise (em paise de INR — 1 INR = 100 paise). Você pode substituir o padrão do sistema de ₹15.000 em três níveis:
Nível
Onde definir
Escopo
Por solicitação
mandate_min_amount_inr_paise em uma sessão de checkout, pagamento ou assinatura
Uma transação
Comerciante
Configurações da empresa
Todas as suas assinaturas em INR
Sistema
—
Padrão de ₹15.000
Prioridade de resolução: substituição por solicitação → configuração do comerciante → padrão do sistema.
Assinaturas em INR com cartões indianos em conectores que não sejam Airwallex
Definir um piso mais alto permite oferecer suporte a cobranças únicas maiores posteriormente (por exemplo, upgrades de plano ou excedentes baseados no uso) sem obrigar os clientes a autorizar novamente. Definir um piso mais baixo aproxima a autorização do cliente do valor real da cobrança, mas limita a margem para futuras cobranças variáveis.
Esta configuração afeta apenas e-mandates registrados para cartões emitidos na Índia (Visa, Mastercard, RuPay) em assinaturas em INR. As assinaturas UPI seguem seu próprio fluxo AutoPay e não são afetadas.
Esta é a diferença mais importante em relação aos pagamentos com cartões internacionais:
1
Charge Initiated (Day 0)
Na data de renovação programada, Dodo inicia a cobrança com o banco.
2
Pre-Debit Notification
O cliente recebe uma notificação do banco sobre o próximo débito.
3
48-Hour Window
O cliente pode cancelar o mandato durante esse período pelo aplicativo do banco.
4
Debit Completed (~48-51 hours)
Após 48 horas (mais até 3 horas adicionais para o processamento bancário), os fundos são debitados.
5
Webhook Sent
O webhook payment.succeeded é enviado após o débito efetivo, não no início.
Não conceda benefícios no início da cobrança. Aguarde o webhook payment.succeeded, que chega aproximadamente 48 a 51 horas após a data programada da cobrança.
// DON'T do this:async function handleSubscriptionRenewal(subscription) { // ❌ Bad: Granting access immediately when charge is initiated grantPremiumAccess(subscription.customer_id);}// DO this:async function handlePaymentWebhook(event) { if (event.type === 'payment.succeeded') { // ✅ Good: Only grant access after payment is confirmed grantPremiumAccess(event.data.customer_id); } if (event.type === 'payment.failed') { // Handle failed payment (mandate cancelled, insufficient funds) revokePremiumAccess(event.data.customer_id); }}
Desenvolva sua aplicação para lidar com o intervalo entre o início da cobrança e o pagamento efetivo. Considere:
Períodos de carência para acesso à assinatura
Comunicação clara com os clientes sobre o tempo de processamento
Cumprimento orientado por webhooks, não por datas
Handle mandate cancellations
Os clientes podem cancelar mandatos pelos aplicativos dos bancos a qualquer momento. Monitore os webhooks subscription.on_hold e solicite que os clientes assinem novamente ou atualizem os métodos de pagamento.
Set appropriate mandate amounts
Para preços variáveis (por exemplo, baseados no uso), avalie se um mandato sob demanda de Rs 15.000 é suficiente. Se as cobranças puderem exceder esse valor, os clientes precisarão autorizar novamente.
Offer UPI prominently
Para clientes indianos, o UPI deve ser a principal opção de pagamento. Muitos usuários o preferem aos cartões devido à familiaridade e à menor fricção.
Se for um comerciante não indiano: Adaptive Currency está habilitado?
upi_collect está incluído em allowed_payment_method_types?
Solução: verifique se o endereço de cobrança contém country: "IN" e billing_currency: "INR".
Subscription charge failed after upgrade
Causa: o valor da nova cobrança excede o limite do mandato existente (limite de Rs 15.000).Solução: o cliente deve atualizar o método de pagamento para estabelecer um novo mandato com o limite correto.
Subscription on hold but customer claims they didn't cancel
Causa: o cliente pode ter cancelado o mandato durante a janela de 48 horas, ou o banco pode ter recusado o débito.Solução: o cliente precisa autorizar novamente o mandato ou atualizar o método de pagamento.
Payment deduction delayed beyond 48 hours
Causa: atrasos na API do banco podem estender o processamento em mais 2 a 3 horas.Solução: isso é esperado. Desenvolva seu sistema para lidar com atrasos variáveis de até aproximadamente 51 horas no total.
Mandate cancelled but subscription still active
Causa: caso específico das regulamentações do RBI — o cancelamento do mandato durante a janela de processamento não cancela imediatamente a assinatura.Solução: a próxima cobrança falhará e a assinatura passará para on_hold. Monitore os webhooks para payment.failed.