Integrate with RevenueCat

Please integrate RevenueCat into our app by adding the RevenueCat SDK and configuring it with our App Store/Google Play products. Also wire the purchase/subscription lifecycle events (e.g., customer info updates and entitlement/subscription changes) so we can track conversions and revenue attribution end-to-end. Make sure subscription status changes are reflected immediately in-app via RevenueCat entitlements.

Web2App Funnels

A web2app funnel describes the steps users go through to move from a website experience to installing and using a mobile app. It typically includes landing on the web, engaging with a prompt (e.g., “Install our app”), initiating the install flow, and completing onboarding. The goal is to measure drop-off at each stage and optimize conversion from web users to app users.

Add Invoices in users local currency

New features upgrade

Bank management upgrade u must be able to select a bank account in which u pick any amount u want to send payouts to like a bank account selection you chose where u want your money to go which account and a switch and a visa visual card for dodo payments for spending, quick pay, transfer money on the Visa card u add how my amount you want to add on the Visa card for spending and Bills

[Umbrella] New payout methods & destinations

Merchants want more ways to receive their money out of Dodo — beyond standard bank/SWIFT transfers. Requests span UPI, stablecoins/crypto, PayPal, gift-card payouts, and a Dodo-hosted wallet/digital bank account, driven by high fees and banking friction in many regions. Originally requested by: Coden, Muslim Plus (with Vansh & Big1400), Prasad, Ayush Agarwal, Vansh ## Consolidated requests ### Add UPI payouts Requested by: Coden Some people cant use their bank, so like it would nice if you would add upi payouts to the users UPI account, allowing local business to scale ### Stable coin payout Requested by: Muslim Plus Please enable payout with stable coin, it is safe with privacy and fast enough _(Merged child posts: "Payout through stablecoins" by Vansh; "Crypto Payouts" by Big1400.)_ ### Global Gift Card Payouts for Platforms Requested by: Prasad I've been thinking about a payout feature that could significantly expand Dodo's utility for platforms and marketplaces. Idea: Gift Card-Based Secondary Payouts — Allow platforms to convert their Dodo payout balance into digital gift cards (via an API provider like Tremendous) — not for personal withdrawal, but to pay their own sellers, users, winners, or affiliates. Core Use Case: Platforms use Dodo as their payment processor, accumulate balance, and then need to distribute earnings or rewards globally. Instead of relying only on bank transfers, they can generate digital gift cards directly from their Dodo balance. Proposed Flow: - Platform accumulates payout balance on Dodo - Platform selects "Create Gift Card Payout" - Chooses country, brand (Amazon, Visa prepaid, etc.), and amount - Dodo deducts amount + 0.5–2% service fee - Dodo calls the gift card provider API - Redemption link is returned via webhook/API response - Platform distributes the gift card to their end user Benefits: Enables instant global micro-payouts; removes banking friction in difficult regions; useful for gaming rewards, affiliate payouts, creator earnings, marketplace sellers; no inventory risk (fully API-based); creates an additional revenue stream on payout volume. With proper KYC, AML controls, payout limits, and fraud monitoring, this could position Dodo not just as a payment processor — but as a flexible global payout infrastructure layer for internet businesses. Happy to expand this into a more detailed technical and revenue breakdown if useful. _(Comment from Coden: "Adding UPI payouts also should help".)_ ### PayPal Payout Requested by: Ayush Agarwal Since you almost integrated PayPal for customer payments are you planing offering payouts for vendors via PayPal? You have lower % commission per transaction comparing to Polar or Paddle but Dodo has quite expensive payouts via SWIFT for non-US and non-India based vendors. $25 fee for SWIFT + in EU we're charged additional $25 for SWIFT transfer so total $50. That's yearly $600-$1200 (considering 1-2 payouts monthly) wasted and going nowhere only for processing payout transactions. Even SEPA would does the job since you have eneity in UK because even though the UK has left the UE, it remains a member of the Single Euro Payments Area (SEPA) and payout in EUR would be 0 then. ### Dodo Payments wallet & digital bank account Requested by: Vansh Enable payouts to a Dodo‑provided digital bank account, with all payout records stored in the dashboard. Include a button to transfer funds to a local bank payout when needed.

onboarding

The onboarding experience is average, initally when I clicked 'get started' it lead me to a dead end, I had to guess how to work around that. Then I filled all the verification forms, but never got any email back to update me on the verification progress as verification components got approved. I did get a welcome email when I signed up though.

Add Idempotency Support to Create Charge for On-Demand Subscriptions

Description: The Create Charge endpoint for on-demand subscriptions currently does not support idempotency checks. As a result, multiple consecutive requests with the same payload can create multiple charges for the same customer. This can lead to duplicate customer charges, particularly when a merchant retries a request because of a timeout, network failure, or a lost response after the initial request was successfully processed. Expected Behavior: The endpoint should support an idempotency key so that repeated requests with the same key are treated as the same operation. If the initial request has already been successfully processed, subsequent requests with the same idempotency key should return the result of the original request instead of creating another charge. Use Case: A merchant sends a Create Charge request, but the response is lost due to a network issue. The merchant retries the request with the same idempotency key. The retry should not create a second charge. Impact: Implementing idempotency would prevent accidental duplicate charges and make the Create Charge API safer and more reliable for merchants handling retries.

[Umbrella] Regional local payment methods & currencies

Multiple merchants are asking Dodo to support regional local payment methods, mobile wallets, and local-currency settlement across South Asia, the Middle East, Latin America, East Asia, and Africa. Adding these local rails would lift checkout conversion and accessibility in markets where international cards are impractical. Originally requested by: Ashley Gomez, Rezwan Ur Rahman Labib, Venkatesh, Arel, Abdelrahman Abdelfattah, Bandar Alrubaysh, Hisako ## Consolidated requests ### Add Bangladesh Local MFS Support (bKash, Nagad, Rocket) & BDT Currency. Requested by: Ashley Gomez Please consider adding support for Bangladeshi local mobile wallets—bKash, Nagad, and Rocket—alongside local BDT currency settlement. The Problem: Bangladeshi buyers face strict government regulations and tight limits on international passport-endorsed USD credit cards. This makes buying global digital products or software nearly impossible for the average consumer. The Solution: Integrating local MFS gateways will allow millions of Bangladeshi users to pay instantly using their local currency. This will instantly increase conversion rates for any digital creator or agency using Dodo Payments to sell in the South Asian market. ### Feature Request: Add Bangladeshi Local Payment Methods (bKash / Nagad / Pathao Pay) Requested by: Rezwan Ur Rahman Labib We'd love support for Bangladeshi local payment methods to make monetization easier for users in Bangladesh. Many of our users prefer mobile wallet payments, and adding options such as bKash, Nagad, or Pathao Pay would significantly improve conversion rates, accessibility, and trust. Why this matters: - Bangladesh has a massive digital payment user base (especially bKash) - Local wallets are far more widely adopted than cards - Improves checkout success rates and reduces friction - Makes your platform far more competitive and accessible in South Asia Requested Feature: Please add integration for one or more of the following: bKash, Nagad, Pathao Pay. If there's a roadmap or timeline for Bangladesh payment support, we'd love to know. Thank you! ### Add SPEI and OXXO payment methods for Mexico Requested by: Venkatesh Please add support for popular local payment methods in Mexico, specifically SPEI bank transfers and OXXO cash payments. Many customers here are already used to paying this way, so having these options in checkout would make it much easier for them to complete their purchases and would improve conversion. ### Add Support for Line Pay, Mainly For Taiwanese Customers Requested by: Arel Many integrations exist on Dodo (such as WeChat Pay i think), but Line Pay is still missing. This would greatly help me and any others building for Taiwan. Every Taiwanese person is super accustomed to using Line Pay, so it'll be beneficial for any Taiwan based projects. ### support EGYPT wallets Requested by: Abdelrahman Abdelfattah support EGYPT wallets like Vodafone cash, fawary, instapay ### Support GCC region Payment option MADA Requested by: Bandar Alrubaysh _(No description provided.)_ ### Add KES as currency option in checkout Requested by: Hisako Hello, I am a user from Kenya. Currently Kenyan Shilling (KES) is not supported in the checkout page. Please add this currency option. Thanks. _(Screenshot attached in original post.)_

Upgrade & downgrade subscriptions via payment links

Summary Allow subscription upgrades and downgrades to be completed via a payment link, not only through the customer's saved payment method. ## Current behavior Today, when a customer upgrades or downgrades a plan, the change is charged automatically against the payment method already saved on the subscription. There is no way to route that plan change through a payment link. ## Request Support upgrade/downgrade via a payment link as well — i.e. generate a link the customer can open to review and confirm/pay for the new plan, rather than relying solely on an on-file, auto-charged payment method. ## Why it matters - Covers subscriptions where no payment method is saved or the saved one has expired/failed. - Lets the customer explicitly review and authorize the new amount (useful for larger upgrades or region/bank flows that require re-authentication). - Enables merchant- or sales-initiated plan changes where the customer completes payment themselves. ## Notes Complements the existing automatic (saved-payment-method) upgrade/downgrade flow — this is an additional path, not a replacement. _Captured by the team from roadmap planning._

Feature Request: Guarded Refund Authorization for AI Agents

Summary: Add a merchant-controlled, one-time authorization mechanism for refund operations performed through Dodo Code Mode MCP / SDK by AI agents. Problem: Dodo's Code Mode MCP can allow an AI agent to invoke client.refunds.create against a live merchant account. Since refunds directly affect merchant funds, merchants need a way to restrict exactly what an AI agent is authorized to execute without requiring another Dodo approval dashboard. Proposed Solution: Allow merchants to create a portable, one-time authorization that explicitly binds a refund operation to: - Merchant/account - Payment ID - Refund items and amounts - Refund reason - Expiry time - One-time usage The authorization would be validated locally by a merchant-controlled gateway before the refund request reaches Dodo. Expected Behavior: - Exact approved refund → Allowed - Modified payment/item/amount/reason → Rejected - Expired authorization → Rejected - Reuse of an already-consumed authorization → Rejected - Provider timeout / unknown outcome → Mark as outcome unknown and prevent blind retry Merchant's Existing Prototype: The merchant has provided a synthetic runnable fixture demonstrating these five scenarios and asked whether the proposed request projection matches the fields that should be protected for the client.refunds.create Code Mode MCP path. Ref: https://github.com/emiliaprotocol/emilia-protocol/tree/4eadad0f3c66ed887893be03f70bb0cb2764cea7/examples/dodo-refund-gate-v1 Value: Provides a safer way for merchants to let AI agents perform refunds while keeping the merchant in control of the exact refund action and avoiding exposure of the API key to the model.

Discount code expiry does not account for timezone

Discount code expiry does not account for timezone like we should know what timezone they expire in should either be clear and we should have a date param like we are mainly working in PST and EST timezone but our discount expire their day ends.

Customer portal: let users view & release their own activated devices

For license-key products with a device activation limit, when customers reinstall their OS, switch devices, or wipe a disk, the old device still occupies an activation slot — so activating a new device shows "Device limit reached." Customers currently cannot free slots themselves — there's no entry in the customer portal to view all activated devices under a license and revoke them. They can only contact the merchant for manual deletion each time. Request: - Add a license-management view in the customer portal where the customer can see all activated devices under their license. - Let them release / revoke a device slot themselves. Impact: Recurring issue that currently requires manual backend processing by the merchant on every device change. _Reported by merchant: Mole (bus_0Ndre3BwB57i3ShiBfln7)_

Discount codes don't allow underscore in the UI but allow in other places

When creating a discount code in the UI, we can't use underscores.While when using the mcp or the api directly it is allowed.

[Umbrella] Merchant onboarding & country availability

Developers and founders in under-served countries are blocked at onboarding because Dodo doesn't recognize their country or their accepted forms of ID. These requests ask for broader country coverage and more identity-document types. Originally requested by: Michailo Levitskiy, Hussein 2 Console, Gentrit Ahmeti, roy ## Consolidated requests ### add IDENTITY VERIFICATION from Ukraine Requested by: Michailo Levitskiy _(No description provided.)_ ### to accept ID verification from lebanese Government, its a small country but it exists on earth Requested by: Hussein 2 Console to accept ID verification from lebanese Government, its a small country but it exists on earth ### Add Support for Kosovo (XK) Requested by: Gentrit Ahmeti Kosovo (XK) is currently not included in the list of supported countries for payment acceptance. I would like to request support for Kosovo, as there is a growing number of developers, freelancers, SaaS founders, and startups who would benefit from using Dodo Payments. Adding Kosovo would enable businesses and creators from Kosovo to access your platform and expand your reach in the Western Balkans region. Use case: - SaaS founders selling software globally - Indie developers and digital product creators - Startups looking for a Merchant of Record solution - Freelancers selling digital services and products Thank you for considering this request. ### Support National IDs and Driver's Licences for Account Verification Requested by: roy I am a developer based in Zambia and noticed that account verification currently only accepts passports. In many countries, users are also able to verify using a driver's licence or national ID card. For many people in Zambia and other countries, a passport is not the most common form of identification, while national IDs and driver's licences are much more accessible. It would be very helpful if Dodo Payments could support additional verification documents such as national IDs and driver's licences for more countries, including Zambia. This would make onboarding much easier and more inclusive for developers and businesses in regions where passports are less common.

[Umbrella] Third-party platform integrations

Merchants want first-class, native integrations connecting Dodo to the third-party platforms they already build on — spanning auth/identity (Clerk), the WordPress commerce ecosystem (SureCart), and marketing/funnel platforms (GoHighLevel). Originally requested by: Vikas Bansal, KG, David Lemon ## Consolidated requests ### Direct Integration Between DoDo Payments and Clerk for Unified Customer Management Requested by: Vikas Bansal It would be extremely valuable if DoDo Payments could offer a native integration with Clerk, allowing customer identities to be shared or synced directly between the two platforms. Today, when using Clerk for authentication and user management, the same customer has to be created and maintained separately inside DoDo Payments. This leads to: - Duplicate customer records across systems - Additional engineering overhead to keep users in sync - Increased risk of data mismatches (email, user ID, metadata, etc.) A first-class integration could enable: - Automatic customer creation in DoDo Payments based on Clerk user IDs - A single source of truth for customer identity - Cleaner mapping between subscriptions, payments, and authenticated users - Reduced maintenance and simpler billing workflows for developers This would significantly improve the developer experience for teams already using Clerk and make DoDo Payments easier to adopt in modern SaaS stacks. ### Surecart Integration Requested by: KG Will be beneficial for surecart users if dodo is integrated with surecart for sellers in wordpress ecosystem as surecart already has a huge userbase and can benefit from dodo pricing as surecart already supports paddle, razorpay, stripe etc ### GoHighLevel Integration Requested by: David Lemon An integration between GoHighLevel and DodoPayments as an external payment provider for selling digital products, SAAS, etc. which would support order bumps, upsells, downsells, calendar payments, etc. https://help.gohighlevel.com/support/solutions/articles/155000002620-how-to-build-a-custom-payments-integration-on-the-platform

URGENT: Payment Method Selection Before Address Input (One-Click Checkout)

Hi Dodo Team, We've noticed that our current checkout flow requires customers to enter their name, address, and other personal details before they can see or select a payment method. This creates unnecessary friction, especially for wallet-based payment methods like Apple Pay, Google Pay, and PayPal. The problem: These payment methods already contain all necessary customer data (name, billing address, email). That's the entire point of wallet payments — a seamless, one-tap checkout experience. Requiring users to manually fill out a form beforehand defeats this purpose. What we'd like to see: - Step 1: Show available payment methods immediately (Apple Pay, Google Pay, PayPal, Credit Card, etc.) - Step 2a (Wallet): If the customer selects Apple Pay / Google Pay / PayPal → authorize directly. Name, address, and email are pulled from the wallet. Done. - Step 2b (Credit Card): If the customer selects Credit Card → show the card form and name/address fields only if they are required and not already known. This is standard behavior across Stripe, Shopify, and other major checkout providers. The wallet payment sheet handles identity verification and address collection natively — there's no need to duplicate this in the checkout UI. Is this something you can support, either as a configuration option or a layout change? Happy to jump on a call to discuss. Best regards

Support independent billing and credit-grant cadences for subscriptions

Merchants want to bill a subscription on one cadence (e.g., annually) while granting credits on a shorter, separate cadence (e.g., monthly) — so customers can't front-load and consume the full period's credit allowance immediately after paying. Currently, credit grants are tied to the subscription's billing cycle only, so merchants have to self-manage interim grants via the Credit Ledger API (creditEntitlements.balances.createLedgerEntry) with manual expires_at windows as a workaround, while still wanting Dodo to remain the source of truth for balances, expiry, rollover, and overage. Native support for a configurable grant cadence independent of the billing cadence would remove this workaround.

Include USD equivalent amount on the refund object/payload

Summary For non-USD payments, the refund object/webhook payload only carries the refunded amount in the presentment currency (e.g. BDT). It does not include the USD equivalent of the refunded amount. The dashboard already shows the refunded USD figure (e.g. "37 of 39 USD refunded"), but that value isn't exposed anywhere in the refund payload — only usd_equivalent_amount exists on the payment object. ## Problem Merchants storing refunds in their own DB currently have to derive the refunded USD value themselves by applying the refund-to-payment ratio against the payment's usd_equivalent_amount. This is error-prone and easy to get wrong for partial refunds. ## Request Expose a usd_equivalent_amount (or equivalent settlement/USD figure) directly on the refund object and refund webhook payloads, so the refunded amount in USD is available out of the box without any client-side calculation. ## Impact - Removes a manual, error-prone calculation for every merchant reconciling non-USD refunds. - Makes refund reporting consistent with the payment object, which already exposes usd_equivalent_amount. _Raised on behalf of a merchant reconciling non-USD (BDT/EUR) refunds into their own Payments table._

Scheduled plan change does not re-attach the new product's meter price — usage bills at the old plan's rate indefinitely

# Scheduled plan change effective_at=next_billing_date) does not re-attach the new product's meter price — usage bills at the old plan's rate indefinitely Business: petnow (test mode) Feature: Subscriptions / Change Plan (v1.93.0 "Change Plan on Next Billing Date") ## Summary When a plan change is scheduled effective_at: "next_billing_date", proration_billing_mode: "full_immediately" — the only mode the API accepts with that timing), the subscription's product_id switches at the boundary as expected, but the subscription's attached usage meter keeps the old product's price_per_unit. Every subsequent renewal invoice bills usage at the old plan's rate while naming the new product on the line item. An immediate change effective_at: "immediately") re-attaches pricing correctly, so the two paths reach the same product with different billing. ## Environment - Subscription: sub_0NgsRDIOYpACfNHqo5G3u (customer cus_0NgsRDHy8LQ6ZhbqXJLGC) - Two products sharing one meter mtr_0Nb6cXrBT6IZZ7Ka4nnBW, "Active pets", aggregation last(pet_count), fixed price $0 on both): - Petify Core (DEV) pdt_0Nb6cwDRX6Qft6tEpHruq — $0.50/unit - Petify Plus (DEV) pdt_0NkHvBH9Y6Se7Qu2rDtco — $0.75/unit ## Steps to reproduce (all timestamps 2026-08-06 UTC; reproduced twice on the same subscription) 1. Put the subscription on Plus via change_plan effective_at=immediately, proration_billing_mode=do_not_bill) → meters[0].price_per_unit = "75" ✓ 2. Schedule a downgrade: change_plan with product_id=, proration_billing_mode=full_immediately, effective_at=next_billing_date → scheduled_change created ✓ 3. Let the boundary pass. The change applies: product_id → Core ✓, but meters[0].price_per_unit stays "75" ✗ 4. Ingest usage events and let two further renewals invoice. ## Actual results | Invoice | Cycle | Line item as printed | Total | |---|---|---|---| | inv_0NkmV4TAoiYfHnlVjqDq4 pay_0NkmV7RQIUQEzPgxUpW1N, 04:38:50Z) | 1st cycle spent fully on Core | "Petify Core (DEV)" + "2222 pets x 0.75 USD" | $1,833.15 | | inv_0NkmwSWJL8XkFftGIgP1K pay_0NkmwVU7eJQFrh8T9Hs40, repro run) | 1st cycle on Core | "1000 pets x 0.75 USD" | $825.00 | | inv_0Nkn8VSKgIX3dSdsnkpqM pay_0Nkn8VbKwOFBZFSBzjqVk) | 2nd consecutive cycle on Core — no plan change anywhere near it | "4000 pets x 0.75 USD" | $3,300.00 | subscriptions.retrieve throughout shows product_id = pdt_0Nb6cwDRX6Qft6tEpHruq (Core) with meters[0].price_per_unit = "75". The state never self-corrects — a "only the transition cycle bills at the old price" interpretation is ruled out by the third invoice. Note the internal contradiction on the invoices themselves: the line names Petify Core while billing a unit price that does not exist anywhere on the Core product. ## Expected After the scheduled change takes effect, usage bills at the new product's meter price ($0.50). Your documentation supports this expectation: - Localized Pricing: "the new plan's price is resolved with the same rules as checkout … This holds everywhere a plan change can originate: the Change Plan API, the Customer Portal, and changes scheduled for the end of the billing period." - Changelog v1.93.0: customers "retain access to their current plan until the end of the billing period." ## Ruled out - Not a configuration issue. No Product Collection is in use, Customer Portal self-service is unused ("Allow Subscription Updates" off); all calls are merchant-API. Under identical settings, the immediate path re-prices correctly. - Not proration-related. Both products have a $0 fixed price; the discrepancy is the meter unit price itself. ## Impact Silent mis-billing on usage-based products after any scheduled plan change — overcharge on downgrades, undercharge on upgrades — invisible to the customer until the invoice arrives. ## Workaround we validated After the scheduled change applies, calling change_plan again with the same product and proration_billing_mode=do_not_bill, effective_at=immediately re-attaches the correct meter price (observed 75 → 50, billing anchor preserved). ## Questions 1. Is this intended behavior or a defect? If a defect, what is the fix timeline? 2. Will a fix retroactively repair subscriptions already in the inconsistent state product_id ≠ attached meter pricing)? 3. Until then, is the no-op immediate change_plan the recommended mitigation? ## Secondary report — product attribution disagrees across surfaces While investigating, we noticed the dashboard payment detail page attributed a payment made on a Core cycle to "Petify Plus" (it appears to render the subscription's current product at view time), while the invoice PDF pins the payment-time product, and the payment API object carries no product at all product_cart: null on subscription renewals). Three surfaces disagree about which product a payment was for — worth aligning, since it makes billing incidents like the above much harder for merchants to diagnose.

Automatic Currency Conversion for Local Pricing

Currently, adding local pricing for a product requires merchants to enter prices manually, country by country and currency by currency. This becomes time-consuming when a product is sold across many countries.It would be helpful to have an automatic currency conversion feature. Merchants could set a base price in one currency, and Dodo Payments would automatically generate equivalent prices for all supported currencies using the current exchange rates.For example, if my product price is ₹149 in India, Dodo Payments could automatically show the converted amount in USD. I could then review the suggested price and adjust it based on my pricing strategy—for example, increasing it to $5 for customers in the United States.Ideally, the feature would:Automatically convert the base price into all supported currencies.Allow merchants to review and edit the generated prices.Make it easy to increase or decrease pricing for individual countries.Include an option to round converted prices to more suitable amounts, such as $4.99 or €4.99.Allow merchants to accept the suggested prices in bulk instead of entering every currency manually.This would make managing localized pricing significantly faster and easier, especially for businesses selling globally.