payout inactive

Dear Team,This is not right. We have provided all services to our client—including timely updates—and the client has made the full payment; yet, your platform is withholding these funds. We submitted all the documents requested by your compliance team on time, but the payment has not been released so far. We would like to know the reason for this. Furthermore, if you require an acknowledgment email from our client, please let us know; we can arrange for that.We hope you have understood our point and will release our payment soon.Thank you

"Brand Name" column in Products List table

products list has no filtering per brand and shows all the products from all the brands/business, it's very confusing most of the times, cause many times different brands can have the same name for their product, so, need to open each to check which one is which

Purchase Confirmation Emails in Regional Languages

Currently, we don't support purchase confirmation emails in regional languages. This is causing issues for customers who don't understand English, and as a result, merchants are raising queries about this.

UPI Intent Deep-Link Support

Request for UPI payments in Dodo Hosted Checkout, particularly: - Direct deep-linking to installed UPI apps on mobile devices - QR-based UPI fallback for desktop users This would reduce friction for Indian mobile customers and improve payment conversion rates.

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

Pre-fill a discount code on static payment links

Problem Static payment links accept no discount parameter. Merchants sharing a link with a coupon have to tell the customer to type the code in themselves, and customers often get it wrong or miss it entirely. Checkout Sessions already support discount_code, so this is a gap between the two checkout methods. Passing discount_code, discountCode, discount, coupon or promo_code on a /buy/{product_id} link all produce a session with the discount fields empty, identical to passing no parameter at all. The parameter is silently dropped. ## Ask 1. Support a discount code query parameter on static payment links, applied to the session the link creates, the same way discount_code works on Checkout Sessions. 2. Ideally lock it so the customer cannot remove or replace it. ## Why Merchants share payment links directly with customers, often one to one. Making the customer type a code they were already given is an avoidable drop-off.

pay what you want subscription feature. Virality Potential

pay what you want subscriptions, where the user could decide how much he would to pay for the subscription monthly, and always upgrade or downgrade for example pay 2 dollars more per month. would be a great community feature for like badges for loyal community supporters, rankings, leaderboard. unique and usable for projects like outbid.lol

Indonesian Local Payment Methods

We would like to request support for popular Indonesian payment methods, particularly: - QRIS - Virtual Accounts (VA) from major Indonesian banks Adding these local payment methods could make checkout more seamless for Indonesian customers and potentially improve payment conversion rates. Requested Feature: Support for QRIS and Indonesian bank Virtual Account payments.

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

Show refund ARN in the dashboard

Problem We do not store the ARN on the refund record, so every merchant request needs a manual lookup in the processor dashboard. Merchants need it so their customer can trace the refund with their bank. ## Ask 1. Persist the ARN on the refund record when the connector returns it 2. Show it on the refund in the dashboard

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

Reuse bank details from other business

Hello instead of manually entering bank details everytime for a new buiness make a way user can reuse bank details from list of business or enter manually etc

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

Grant subscription to users without payment method

Currently I dont see any way to gift/grant users a subscription to a product, would be great to have this as a feature

Add support where small amount of the transaction goes to any charity you choose

[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

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

Support Multiple Images per Product Request

Add the ability to upload multiple images for a single product in the Dodo Dashboard.

Add retry_attempt and checkout_session_id to the payments list response

Problem GET /payments omits several fields that are present on GET /payments/{id}, which forces a fetch per payment for work that should be one list call. Missing from the list item today: - retry_attempt - checkout_session_id - error_code and error_message - billing (so no billing country) - card_issuing_country and card_type The list does carry status, currency, payment_method, payment_method_type, card_network, card_last_four, invoice_id, subscription_id, metadata, refund_status, dispute_status and payment_provider. ## Why it matters Measuring an authorization rate is impractical. A merchant wanting a decline-rate breakdown by country has to page the list, then issue an individual fetch for every row to get error_code and billing country. With page_size capped at 100, that is one request per payment across their whole history. card_issuing_country, which is the better signal for a card-issuance rate than billing country, is also single-fetch only. Retries cannot be excluded from a list-derived rate. Our own renewal retries appear as separate payment rows. Without retry_attempt on the list there is no way to filter to first attempts, so any rate computed from the list silently over-counts attempts. Response-loss recovery is weaker than it needs to be. When a merchant loses a checkout session_id, the documented fallback is to scan GET /payments by created_at and match on their own reference in metadata. That works, but because checkout_session_id is not on the list item they cannot confirm the match against the session, only against their own metadata. ## Requested Add to the payments list item: 1. retry_attempt — unblocks first-attempt filtering 2. error_code and error_message — unblocks decline analysis without N fetches 3. checkout_session_id — completes the recovery path 4. billing or at minimum a billing country field, and card_issuing_country Items 1 and 2 are the highest value, since together they turn authorization-rate measurement from N+1 requests into one. ## Related Two adjacent inconsistencies worth cleaning up in the same pass: - updated_at exists on PaymentResponse but is always null. It should either be populated or removed. - retry_attempt counts our scheduled retries, but manual retries number from their own sequence and payment-method-update charges keep 0. Worth documenting the semantics wherever it is exposed, since merchants reasonably read it as an attempt counter.

Idempotency keys on create endpoints

Problem There is no idempotency support on any create endpoint. No handler reads an Idempotency-Key header, and the SDK's per-request idempotencyKey option sends nothing because the Stainless config declares no idempotency_header. Merchants who test for it find the option silently does nothing. The only idempotency that exists today is a body field named idempotency_key on three endpoints: webhook create, credit-entitlement ledger entry, and wallet ledger entry. Nothing else has it. ## Why it matters A request timeout is normal client behaviour, and a retry after one is what every well-built integration does. Today that retry is indistinguishable from a new command, and on some endpoints it duplicates real money movement. Checkout creation. If a merchant's server loses the session_id after we create the session, there is no way to recover it or prove it is unusable. There is no lookup by a merchant reference, metadata is not queryable, there is no list endpoint for sessions, and there is no expire or invalidate operation. Their only option is to create another session and let the orphan lapse. Plan change. Tested in test mode: two identical POST /subscriptions/{id}/change-plan calls sent back to back both produced a charge, of INR 272,988 and INR 273,466. The amounts differ because both ran the pricing path independently, so there was no serialisation at all. A guard does exist and returns 409 once a payment is in flight, but it does not engage on concurrent or rapid duplicates. Payment-method-update link. On an active subscription there is no guard. Every call mints a fresh link and a fresh payment row, so a double submit leaves two live links. ## Requested An Idempotency-Key header honoured across create endpoints, with the usual semantics: replaying the same key returns the original resource, reusing a key with different input is rejected, and the key is scoped per business and environment with a documented retention window. Priority order by blast radius: 1. POST /subscriptions/{id}/change-plan — duplicates a real charge 2. POST /checkouts — unrecoverable lost session 3. POST /subscriptions/{id}/update-payment-method — duplicate links 4. POST /payments, POST /subscriptions, POST /refunds Also worth fixing alongside: the SDK exposes an idempotencyKey option that has no effect. Either wire it to a real header or remove it, because right now it actively misleads integrators into thinking they are protected. ## Interim guidance being given to merchants Gate retries on their own side, and key fulfilment on the returned payment_id rather than on anything they sent. That works but it pushes our race conditions onto them.