Skip to main content

Quick Start

Create your first checkout session in under 5 minutes

API Reference

Full API documentation and interactive testing

Preview Endpoint

Calculate pricing and taxes before creating a session
Session Validity: Checkout sessions expire after 24 hours by default, or 15 minutes when confirm: true.
Single-Use Links: The checkout_url is not reusable. Generate a fresh session for each customer and payment attempt rather than sharing or reusing a link.

Prerequisites

You need:
  • An active Dodo Payments merchant account
  • API credentials from Developer → API Keys in the dashboard
  • At least one product created in Products

Creating Your First Checkout Session

API Response

All methods return:
Only session_id is guaranteed to be present. When payment_method_id is provided, the charge processes immediately and checkout_url is null. Use the returned payment_id instead. When confirm: true, the payment is created at session-creation time, and the response also includes payment_id, client_secret, and publishable_key for use with the Dodo Payments checkout SDK.

Redirect Your Customer

1

Extract the checkout URL

Get checkout_url from the API response.
2

Redirect to checkout

Send your customer to the URL:
Alternatively, open in a new window:
3

Handle the return

After payment, customers are redirected to your return_url with query parameters:Example redirect:
Instead of redirecting, you can embed checkout directly in your page using Overlay Checkout (modal), Inline Checkout (embedded), or Mobile SDKs (native apps). All consume the same session URL.

Check Session Status

To check a session’s status, call Get Checkout Session (GET /checkouts/{id}). The response has the session id, created_at, customer_email, and customer_name, plus payment_id and payment_status. Both payment fields are null while the customer is still entering details. After the customer submits payment, payment_status holds the payment’s status, such as succeeded, failed, or processing. Use webhooks as the source of truth for fulfillment.

Request Body

Required Fields

array
bắt buộc
Array of products to include in the checkout session. Each product must have a valid product_id from your dashboard.Bạn có thể kết hợp các sản phẩm thanh toán một lần với một sản phẩm đăng ký trong cùng một phiên. Giỏ hàng cũng có thể chứa từ hai sản phẩm đăng ký trở lên, nhưng khi đó không thể chứa sản phẩm thanh toán một lần. Xem Giỏ hàng nhiều đăng ký. Một giỏ hàng chứa tối đa 20 sản phẩm.
Find Your Product IDs: You can find product IDs in your Dodo Payments dashboard under Products → View Details, or by using the List Products API.

Optional Fields

object
Customer information. You can either attach an existing customer using their ID or create a new customer record during checkout.
object
Billing address information for accurate tax calculation, fraud prevention, and regulatory compliance.Khi confirm: true, tất cả các trường địa chỉ thanh toán đều bắt buộc, trừ khi minimal_address là true.
array
Control which payment methods are available to customers during checkout. This helps optimize for specific markets or business requirements.Common options: credit, debit, upi_collect, apple_pay, google_pay, amazon_pay, klarna, affirm, afterpay_clearpay, cashapp, ach, multibanco, bancontact_card, eps, ideal, blik, gcash, ali_pay_hk, fps, touch_n_go, paypalSee the Create Checkout Session API reference for the complete list.
Always include credit and debit as fallback options to prevent checkout failures when preferred payment methods are unavailable.
Example:
string
Override the default currency selection with a fixed billing currency. Uses ISO 4217 currency codes.Supported Currencies: USD, EUR, GBP, CAD, AUD, INR, and moreExample: "USD" for US Dollars, "EUR" for EurosTrường này chỉ có hiệu lực khi adaptive pricing được bật. Nếu adaptive pricing bị tắt, API sẽ loại bỏ trường này và tiền tệ được lấy từ giá sản phẩm hoặc quốc gia thanh toán.
boolean
mặc định:"false"
Display previously saved payment methods for returning customers, improving checkout speed and user experience.
string
URL to redirect customers after payment completion. Dodo Payments appends query parameters to your URL on redirect (see the redirect table above).Example redirect URLs:
Use the license_key and email query parameters to display license keys or send a confirmation immediately on your return page, without needing an extra API call.
string
URL to redirect customers when they click the back button or cancel the checkout session. If not provided, the back button will not be displayed.Set a cancel_url to give customers a clear way to return to your site without completing the purchase.
boolean
mặc định:"false"
If true, finalizes all session details immediately. The API throws an error if required data is missing.Khi confirm: true:
  • Tất cả các trường địa chỉ thanh toán đều bắt buộc (chỉ country và zipcode khi minimal_address là true)
  • Có thể cung cấp payment_method_id để xử lý khoản phí ngay lập tức
  • Phiên hết hạn sau 15 phút thay vì 24 giờ
  • Bắt buộc phải có customer_id hiện có nếu cung cấp payment_method_id
array
Apply one or more stacked discount codes to the checkout session. Codes are applied in array order (the first code reduces the starting price, the second reduces the already-discounted price, and so on), up to a maximum of 20 codes per session.When Purchasing Power Parity is enabled, the starting price is the PPP-adjusted amount, not the base price.
The singular discount_code field below is deprecated but still fully supported. It cannot be combined with discount_codes in the same request.
string
không còn sử dụng
Deprecated — prefer discount_codes for new integrations. This field still works for backward compatibility, but cannot be combined with discount_codes in the same request.
object
Custom key-value pairs to store additional information about the session.
boolean
Override merchant default 3DS behaviour for this session.
boolean
mặc định:"false"
Enable minimal address collection mode. When enabled, the checkout only collects:
  • Country: Always required for tax determination
  • ZIP/Postal code: Only in regions where it’s necessary for sales tax, VAT, or GST calculation
Điều này giảm đáng kể trở ngại khi thanh toán bằng cách loại bỏ các trường biểu mẫu không cần thiết.Với confirm: true, chỉ zipcode (cùng với country) là bắt buộc; các trường địa chỉ thanh toán khác vẫn là tùy chọn.
string
Phương thức thanh toán đã lưu thuộc về customer được đính kèm. Yêu cầu confirm: true và customer.customer_id hiện có. Phương thức thanh toán được xác thực về tính đủ điều kiện theo tiền tệ của khoản thanh toán. Khi được đặt, khoản phí sẽ được xử lý ngay lập tức và checkout_url được trả về dưới dạng null. Thay vào đó, hãy sử dụng payment_id được trả về.
Nếu là true, trả về URL thanh toán rút gọn thay vì URL phiên đầy đủ.
string
ID bộ sưu tập sản phẩm cho quy trình thanh toán dựa trên bộ sưu tập. Khi đặt giá trị này, hãy truyền một mảng product_cart rỗng. Không thể áp dụng trước mã giảm giá khi tạo phiên. Xem Bộ sưu tập sản phẩm.
string
Mã số thuế của customer (ví dụ: số VAT). Yêu cầu billing_address cùng với một country.
string
Tên doanh nghiệp hoặc tên pháp lý tùy chọn liên kết với mã số thuế, tối đa 250 ký tự. Khi được cung cấp cùng với một tax_id hợp lệ, tên này được hiển thị trên hóa đơn thay cho tên cá nhân của customer.
integer
Ghi đè ngưỡng mandate cấp merchant (tính bằng paise INR) cho các e-mandate INR trên thẻ Ấn Độ.Số tiền mandate gửi đến processor là max(this_floor, actual_billing_amount), vì vậy đây thực tế là giới hạn ủy quyền hiển thị cho customer bất cứ khi nào số tiền thanh toán thấp hơn. Khi không được đặt, cài đặt của merchant sẽ được áp dụng; nếu cài đặt đó cũng không được đặt, mặc định hệ thống là ₹15,000.
object
Tùy chỉnh giao diện và hành vi của giao diện thanh toán.
object
Cấu hình các tính năng và hành vi cụ thể cho phiên thanh toán.
array
Thu thập thêm thông tin từ customer trong quá trình thanh toán bằng các trường biểu mẫu tùy chỉnh. Bạn có thể xác định tối đa 5 trường tùy chỉnh cho mỗi phiên thanh toán. Phản hồi của customer được đưa vào payload webhook và có sẵn qua API.
Phản hồi của customer đối với các trường tùy chỉnh được đưa vào:
  • Webhooks: payment.succeeded, subscription.active và các payload sự kiện liên quan khác chứa mảng custom_field_responses
  • Response API: Các object payment và subscription bao gồm custom_field_responses
object
Cấu hình bổ sung cho các phiên thanh toán chứa sản phẩm đăng ký.

Ví dụ về cách sử dụng

Thanh toán đơn giản cho một sản phẩm

Giỏ hàng nhiều sản phẩm

Giỏ hàng nhiều đăng ký

Để bán nhiều sản phẩm đăng ký trong một lần thanh toán, hãy thêm từ hai sản phẩm đăng ký trở lên vào product_cart. Customer thanh toán một lần, còn Dodo Payments tạo một payment, một invoice và một subscription cho mỗi sản phẩm. Mỗi subscription có chu kỳ thanh toán riêng và tự gia hạn độc lập, vì vậy sản phẩm theo tháng và sản phẩm theo năm có thể cùng nằm trong một giỏ hàng.
Giỏ hàng nhiều đăng ký có các giới hạn sau:
  • Không thể chứa sản phẩm thanh toán một lần. API từ chối request với 422.
  • Chứa tối đa 20 sản phẩm đăng ký.
  • Không thể liệt kê cùng một sản phẩm hai lần. Để bán nhiều hơn một đơn vị sản phẩm, hãy đặt quantity thay vào đó.
  • Không thể sử dụng hình thức tính phí on-demand (subscription_data.on_demand).
  • Mã giảm giá áp dụng cho giỏ hàng được tính là một lần sử dụng.
subscription_data.trial_period_days áp dụng cho mọi subscription trong giỏ hàng. Nếu không có giá trị này, mỗi subscription sử dụng thời gian dùng thử được đặt trên sản phẩm riêng. Khi bạn không đặt giá trị này và Prevent Trial Misuse đang bật, sản phẩm mà customer đã dùng thử trước đó sẽ bắt đầu mà không có thời gian dùng thử. Payment kết quả có is_multi_subscription: true và liệt kê mọi subscription mà payment khởi tạo trong subscription_ids. subscription_id của payment là null vì không có subscription riêng lẻ nào sở hữu payment. Webhook payment.succeeded chứa các trường tương tự. Đọc is_multi_subscription để xác định loại payment, không phải độ dài của subscription_ids. Sau khi payment thành công, bạn nhận được một sự kiện payment.succeeded cho giỏ hàng và một sự kiện subscription.active cho mỗi subscription. Từ đó, mỗi subscription tự gia hạn, thay đổi plan và hủy độc lập, với một invoice riêng cho mỗi lần gia hạn. Tất cả subscription từ một giỏ hàng dùng chung phương thức thanh toán mà customer đã sử dụng khi thanh toán. Khi bạn cập nhật phương thức thanh toán của một subscription, Dodo Payments chuyển phương thức thanh toán mới sang mọi subscription từ cùng giỏ hàng có cùng settlement currency và billing currency, đồng thời là active, on_hold, past_due hoặc paused. Mọi subscription từ một giỏ hàng bắt đầu với cùng settlement currency và billing currency, ngay cả khi sản phẩm của chúng có tiền tệ giá khác nhau. Một thay đổi sau đó, chẳng hạn thay đổi plan, có thể chuyển subscription sang settlement currency hoặc billing currency khác. Subscription đó giữ phương thức thanh toán cũ, vì vậy hãy cập nhật riêng. Đối với subscription on_hold, bản cập nhật chỉ thử lại invoice chưa thanh toán của subscription đó.

Subscription có thời gian dùng thử

Thanh toán đã xác nhận trước

Thanh toán có ghi đè tiền tệ

Phương thức thanh toán đã lưu cho customer quay lại

Thanh toán B2B có thu thập mã số thuế

Thanh toán chủ đề tối với các mã giảm giá xếp chồng

Phương thức thanh toán theo khu vực (UPI cho Ấn Độ)

Để biết thông tin chi tiết về cấu hình và kiểm thử UPI, xem trang Phương thức thanh toán tại Ấn Độ.

Thanh toán BNPL (Mua trước, trả sau)

Để biết thông tin chi tiết về cấu hình và kiểm thử BNPL, xem trang Mua trước, trả sau (BNPL).

Thanh toán tức thì với phương thức thanh toán hiện có

Liên kết rút gọn cho URL payment gọn gàng hơn

Bỏ qua trang thành công payment với chuyển hướng ngay lập tức

Buộc sử dụng một ngôn ngữ

Thu thập các trường tùy chỉnh

Xem trước các phiên thanh toán

Sử dụng endpoint Preview Checkout Session để tính giá, thuế và tổng tiền trước khi tạo phiên. Điều này hữu ích khi hiển thị thông tin giá chính xác trên trang web của bạn.
current_breakup.subtotal được xem trước đã phản ánh Purchasing Power Parity và Charm Pricing nếu các tính năng này áp dụng cho sản phẩm.
Khi giỏ hàng chứa sản phẩm đăng ký, response xem trước cũng trả về một next_billing_date — bản xem trước của ngày thanh toán sắp tới, để bạn có thể hiển thị ngày này trước khi subscription được tạo. Ngày được tính tương đối với hiện tại: now + trial period khi áp dụng thời gian dùng thử, nếu không thì now + one payment frequency. Trường này bị bỏ qua đối với giỏ hàng chỉ chứa sản phẩm thanh toán một lần. Đây là ước tính dựa trên thời điểm xem trước; next_billing_date chính thức được đặt khi subscription được kích hoạt.
Bản xem trước cũng trả về trial_period_days (thời lượng dùng thử thực tế, miễn phí hoặc có phí) và trial_amount (phí dùng thử trên mỗi đơn vị sau giảm giá, tính theo đơn vị nhỏ nhất của tiền tệ giá). trial_amount chỉ xuất hiện đối với dùng thử có phí và là null đối với dùng thử miễn phí hoặc không dùng thử. Sử dụng current_breakup cho tổng tiền đã tính thuế thực sự phải trả hôm nay.
Đối với giỏ hàng nhiều đăng ký, response cũng trả về một mảng subscriptions với một mục cho mỗi subscription: product_id, amount_due_now, tax_due_now, recurring_amount, recurring_tax, trial_period_days và next_billing_date. next_billing_date cấp cao nhất là ngày sớm nhất trong giỏ hàng, còn trial_period_days và trial_amount cấp cao nhất là null. Đọc các khoản tiền từ subscriptions và current_breakup. recurring_breakup cộng tổng số tiền gia hạn của mọi subscription, ngay cả khi chúng gia hạn vào các ngày khác nhau, vì vậy hãy đọc từng lần gia hạn từ subscriptions.
Nếu bạn đang sử dụng Dynamic Links, Checkout Sessions mang lại nhiều tính linh hoạt hơn. Với Dynamic Links, bạn phải cung cấp đầy đủ địa chỉ thanh toán của customer. Với Checkout Sessions, bạn có thể truyền bất kỳ thông tin nào mình có và quy trình thanh toán sẽ thu thập phần còn lại. Ví dụ:
  • Chỉ cung cấp quốc gia thanh toán của customer, sau đó thanh toán sẽ thu thập các thông tin còn lại.
  • Hoặc cung cấp toàn bộ thông tin và đặt confirm: true để chuyển thẳng đến trang payment.
Việc di chuyển rất đơn giản: cập nhật integration để sử dụng API Checkout Sessions hoặc phương thức SDK, điều chỉnh payload request cho phù hợp với định dạng Checkout Sessions là xong. Không cần xử lý thêm.

Tài nguyên liên quan

Overlay Checkout

Mở thanh toán dưới dạng modal overlay trên trang của bạn

Inline Checkout

Nhúng thanh toán trực tiếp vào trang của bạn

Mobile Integration

Tích hợp thanh toán vào ứng dụng di động native

Webhooks

Lắng nghe các sự kiện payment và subscription

Payment Methods

Các phương thức thanh toán được hỗ trợ theo khu vực

Subscriptions

Thanh toán định kỳ và quản lý subscription
Lần sửa đổi cuối 8 tháng 10, 2026