[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.

Feature Request: Metadata Filtering & Dodo Sync Support for Usage Events

Summary We would like to request the following enhancements for usage events: 1. Support filtering usage events by custom metadata fields in the usage_event_list API. 2. Add usage event synchronization support to dodo-sync. Problem Many applications emit usage events with rich metadata to attribute costs across projects, sessions, operations, or other business dimensions. While this metadata is used for billing, it cannot currently be used to query or retrieve usage events through the API. Additionally, dodo-sync currently syncs customers, payments, subscriptions, and licenses, but not usage events. This requires developers to build and maintain their own synchronization pipeline. Proposed Enhancements - Extend usage_event_list to support filtering by metadata fields or arbitrary metadata key-value pairs. - Add usage event synchronization support to dodo-sync, allowing merchants to keep their analytics and reporting systems in sync without implementing custom ingestion pipelines. Benefits - Simplifies reporting and analytics by custom business dimensions. - Reduces the need to paginate and aggregate all usage events externally. - Enables easier integration with data warehouses and BI tools. - Improves developer experience by allowing usage events to be synchronized alongside other Dodo resources.

The redirect time is too fast

Tthe redirect of 5 seconds on Dodo Payments page back to merchant's site is too short. Can you please give merchants the ability via API to increase this timer if they choose?

[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.)_

A pop up which asks "Why do you want to cancel the subscription" in manage subscriptions page while user is cancelling

Make the pop up box customizable.

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._

Give option to search for a user using their email id in subscription/transactions rather than just customer ID

Option to export dashboard data/analytics into an excel/csv sheet

Navigation between different subscriptions in customer portal.

Currently, If a customer has multiple subscriptions and click on 'manage subscription' in one subscription, there is no way to go back to the main customer portal page.

Support i64 for price amounts instead of i32

Summary Increase the underlying price field from i32 to i64 to support larger price values and remove integer limitations for high-value products. Current behavior The price field is currently represented as a 32-bit signed integer (i32). This imposes a hard upper limit on the maximum value that can be stored, causing product creation or price updates to fail once that limit is exceeded. As a result, merchants with high-value products or annual/enterprise pricing can encounter integer overflow errors despite the pricing itself being valid. Request Change the underlying price representation from i32 to i64 across the pricing system and APIs. This would significantly increase the supported price range while remaining backward compatible for existing integrations. Why it matters - Removes an implementation-imposed ceiling on product pricing. - Supports high-value products and enterprise pricing across all supported currencies. - Prevents integer overflow errors when creating products or localized prices. - Future-proofs the pricing model as merchants expand into markets with larger nominal currency values or introduce higher-priced offerings. - Avoids the need for currency-specific handling or workarounds. Notes - This is an implementation-level improvement and should not introduce breaking changes for existing API consumers. - Existing integrations using i32-compatible values would continue to function unchanged, while merchants requiring larger price values would no longer be constrained by the current integer limit.

Transactional emails show USD instead of the charged currency (INR)

We are an Indian merchant selling a subscription priced in INR. A customer paid Rs 499.00 by UPI (payment pay_0NkAxrL9WCC4...KJO1, INR product, tax-inclusive, GST shown as Rs 422.88 + Rs 76.12). The dashboard transaction row correctly shows Rs 499.00. However the cancellation confirmation email sent to the customer showed "Price: $5.22 USD" instead. 499 / 5.22 = 95.59, so this is the INR amount converted to USD at the prevailing FX rate, not the USD plan price (our USD plan is $7.99). Two problems this causes: (1) the customer is quoted an amount and a currency they never agreed to and that does not match our pricing page, which reads as a hidden FX charge and generates support tickets and chargeback risk; (2) because it is an FX conversion, the same Rs 499 renders as a different USD figure each month, so two identical invoices show two different prices. Request: transactional emails should display the currency the customer was actually charged in. For Indian merchants this also matters for invoice/GST consistency, since the tax invoice must be in INR.

[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.

Pre applied discount code on checkout for a specific user

Feature of pre applied discount code on checkout for a specific user.

[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

Allow adding / editing a customer's Tax ID (GST/VAT) on an already-issued invoice

Currently a customer's GSTIN (Business Tax ID) can only be captured at checkout. If it's missed or entered wrong, there's no way to add or correct it afterward — not via the dashboard, customer portal, or API (the invoice is read-only and there's no PATCH on a completed payment). This blocks Indian B2B customers from claiming input tax credit, since their GSTIN must appear on the tax invoice. Requested feature: let the merchant (or customer via portal) add/edit the Business Tax ID on an issued invoice and regenerate the tax invoice with it ideally supported across dashboard, customer portal, and API. Real example: merchant Arpit Bansal a ₹26,550 B2B payment (₹4,050 GST @18%) to a CA firm where the customer's GSTIN was missed at checkout, with no way to correct the invoice afterward.

Customer Portal: Self-serve license deactivation

Please add license activation management to the customer portal, so customers can: - View active device instances - Deactivate an instance (and reactivate later from the app). This one is what matters the most. Why this matters: users often lose access to old machines, and without this they must contact support for manual reset. Polar.sh has this on their customer portal. The activation shows the machine name on which the activation is on, and the “X” deactivates it directly from the customer portal. That makes it so the license becomes useable again by freeing up the space.

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

Customer portal is not brand aware: shows the primary brand's name and mixes billing history across brands

I have two brands under one business. A primary brand (a books store) and a secondary brand (a developer education subscription). Products, payments and subscriptions are correctly tagged with brand_id, and invoice PDFs are correctly branded per brand, which is great. The hosted customer portal is the one place that is not brand aware, and there is no way to work around it from my side. Two problems: 1. The portal always renders under the primary brand's name and logo. So a customer who subscribed on my second brand clicks "manage billing" on that site, and lands on a page titled with my books store. They have never heard of that business. On a billing page this looks like a mis click or a phishing page, which is the worst possible moment to confuse someone about who they are paying. 2. Billing history is not filtered by brand. Dodo reuses one customer record per email across the whole business, so a customer who has bought from both brands sees both sets of payments mixed together in one list. It also quietly reveals that the two sites are the same business, which is not something I want to disclose. Why I cannot fix this myself: customerPortal.create only accepts customer_id, return_url and send_email. There is no brand_id argument, and no business setting to scope it. Compare this to payments.list and subscriptions.list, which both accept brand_id and work perfectly. What I would like: - customerPortal.create to accept an optional brand_id, which scopes both the branding and the billing history to that brand - or the portal to infer the brand from the subscription being managed Related: webhook endpoints have the same shape of problem. I was told on Discord that brand scoped webhook urls are being worked on. The portal feels like the same gap in the same place. For now I have had to rebuild billing history and invoice downloads in my own app using payments.list with brand_id plus invoices.payments.retrieve, and drop the portal link entirely. That works, except payment methods, which have no public API at all, so there is no way to let a customer change their payment method without sending them to a portal branded as a different business.

More user friendly payment failure error description

please consider improving error description and instead displaying raw error message show something more user friendly something like "Unfortunately transaction could not be authenticated by your bank. Please try again or use different payment method."

Support for Dynamic/PWYW Prices in WooCommerce Plugin (Listeo Ad Campaigns)

Please add support for custom/dynamically calculated prices (Pay-What-You-Want override) in the official WooCommerce plugin so products like Listeo Ad Campaigns can pass custom checkout amounts without failing session creation.