Tổng quan
Các đăng ký theo yêu cầu cho phép bạn ủy quyền phương thức thanh toán của khách hàng một lần và sau đó tính phí các khoản biến đổi bất cứ khi nào bạn cần, thay vì theo lịch trình cố định. Tính năng này có sẵn cho tất cả các tài khoản—không cần phê duyệt. Sử dụng hướng dẫn này để:- Tạo một đăng ký theo yêu cầu (ủy quyền một mệnh lệnh với giá ban đầu tùy chọn)
- Kích hoạt các khoản phí tiếp theo với số tiền tùy chỉnh
- Theo dõi kết quả bằng cách sử dụng webhooks
Điều kiện tiên quyết
- Tài khoản thương nhân Dodo Payments và khóa API
- Bí mật webhook được cấu hình và một điểm cuối để nhận sự kiện
- Một sản phẩm đăng ký trong danh mục của bạn
Cách thức hoạt động của đăng ký theo yêu cầu
- Bạn tạo một đăng ký với đối tượng
on_demandđể ủy quyền một phương thức thanh toán và tùy chọn thu phí ban đầu. - Sau đó, bạn tạo các khoản phí đối với đăng ký đó với số tiền tùy chỉnh bằng cách sử dụng điểm cuối tính phí chuyên dụng.
- Bạn lắng nghe các webhook (ví dụ:
payment.succeeded,payment.failed) để cập nhật hệ thống của bạn.
Tạo một đăng ký theo yêu cầu
Điểm cuối: POST /checkouts Các trường yêu cầu chính (nội dung):Vui lòng tìm chúng trong Tạo Phiên Thanh toán
Tạo một đăng ký theo yêu cầu
- Node.js SDK
- Python SDK
- Go SDK
- cURL
Success
Tính phí một đăng ký theo yêu cầu
Sau khi mệnh lệnh được ủy quyền, tạo các khoản phí khi cần. Điểm cuối: POST /subscriptions/{subscription_id}/charge Các trường yêu cầu chính (nội dung):Tham số nội dung yêu cầu tính phí
Tham số nội dung yêu cầu tính phí
Số tiền để tính phí (trong đơn vị tiền tệ nhỏ nhất). Ví dụ: để tính phí $25.00, hãy truyền
2500.Tùy chọn ghi đè tiền tệ cho khoản phí.
Tùy chọn ghi đè mô tả cho khoản phí này.
Nếu đúng, bao gồm phí tiền tệ thích ứng trong
product_price. Nếu sai, phí sẽ được thêm vào.Thông tin bổ sung cho khoản thanh toán. Nếu bị bỏ qua, thông tin đăng ký sẽ được sử dụng.
- Node.js SDK
- Python SDK
- Go SDK
- cURL
Success
Thử lại thanh toán
Hệ thống phát hiện gian lận của chúng tôi có thể chặn các mẫu thử lại mạnh mẽ (và có thể đánh dấu chúng là thử nghiệm thẻ tiềm năng). Tuân theo chính sách thử lại an toàn.Nguyên tắc cho các chính sách thử lại an toàn
- Cơ chế lùi: Sử dụng lùi theo cấp số nhân giữa các lần thử lại.
- Giới hạn thử lại: Giới hạn tổng số lần thử lại (tối đa 3–4 lần).
- Lọc thông minh: Chỉ thử lại trên các lỗi có thể thử lại (ví dụ: lỗi mạng/nhà phát hành, không đủ tiền); không bao giờ thử lại các từ chối cứng.
- Ngăn chặn thử nghiệm thẻ: Không thử lại các lỗi như
DO_NOT_HONOR,STOLEN_CARD,LOST_CARD,PICKUP_CARD,FRAUDULENT,AUTHENTICATION_FAILURE. - Thay đổi thông tin bổ sung (tùy chọn): Nếu bạn duy trì hệ thống thử lại của riêng mình, phân biệt các lần thử lại qua thông tin bổ sung (ví dụ:
retry_attempt).
Lịch trình thử lại được đề xuất (đăng ký)
- Lần thử lại đầu tiên: Ngay lập tức khi bạn tạo khoản phí
- Lần thử lại thứ hai: Sau 3 ngày
- Lần thử lại thứ ba: Sau 7 ngày nữa (tổng cộng 10 ngày)
- Lần thử lại thứ tư (cuối cùng): Sau 7 ngày nữa (tổng cộng 17 ngày)
Tránh các lần thử lại bùng nổ; căn chỉnh theo thời gian ủy quyền
- Gắn các lần thử lại với dấu thời gian ủy quyền ban đầu để tránh hành vi “bùng nổ” trên toàn bộ danh mục của bạn.
- Ví dụ: Nếu khách hàng bắt đầu một thử nghiệm hoặc mệnh lệnh vào lúc 1:10 chiều hôm nay, lên lịch các lần thử lại tiếp theo vào lúc 1:10 chiều trong các ngày tiếp theo theo lịch trình lùi của bạn (ví dụ: +3 ngày → 1:10 chiều, +7 ngày → 1:10 chiều).
- Ngoài ra, nếu bạn lưu trữ thời gian thanh toán thành công cuối cùng
T, hãy lên lịch lần thử tiếp theo vàoT + X daysđể duy trì sự căn chỉnh theo thời gian trong ngày.
Múi giờ và DST: sử dụng một tiêu chuẩn thời gian nhất quán cho việc lập lịch và chỉ chuyển đổi để hiển thị nhằm duy trì các khoảng thời gian.
Mã từ chối bạn không nên thử lại
STOLEN_CARDDO_NOT_HONORFRAUDULENTPICKUP_CARDAUTHENTICATION_FAILURELOST_CARD
Để có danh sách đầy đủ các lý do từ chối và liệu chúng có thể được người dùng sửa chữa hay không, hãy xem tài liệu
Thất bại giao dịch.
Hướng dẫn thực hiện (không có mã)
- Sử dụng một bộ lập lịch/ hàng đợi mà duy trì các dấu thời gian chính xác; tính toán lần thử tiếp theo tại thời điểm chính xác (ví dụ:
T + 3 daysvào cùng một HH:MM). - Duy trì và tham chiếu thời gian thanh toán thành công cuối cùng
Tđể tính toán lần thử tiếp theo; không gom nhiều đăng ký vào cùng một thời điểm. - Luôn đánh giá lý do từ chối cuối cùng; dừng thử lại cho các từ chối cứng trong danh sách bỏ qua ở trên.
- Giới hạn số lần thử lại đồng thời theo từng khách hàng và theo từng tài khoản để ngăn chặn các đợt tăng đột biến không mong muốn.
- Giao tiếp chủ động: gửi email/SMS cho khách hàng để cập nhật phương thức thanh toán của họ trước lần thử tiếp theo đã lên lịch.
- Sử dụng thông tin bổ sung chỉ để quan sát (ví dụ:
retry_attempt); không bao giờ cố gắng “tránh” các hệ thống gian lận/rủi ro bằng cách xoay vòng các trường không quan trọng.
Theo dõi kết quả bằng webhooks
Triển khai xử lý webhook để theo dõi hành trình của khách hàng. Xem Triển khai Webhooks.- subscription.active: Mệnh lệnh đã được ủy quyền và đăng ký đã được kích hoạt
- subscription.failed: Tạo không thành công (ví dụ: thất bại mệnh lệnh)
- subscription.on_hold: Đăng ký bị tạm hoãn (ví dụ: trạng thái chưa thanh toán)
- payment.succeeded: Tính phí thành công
- payment.failed: Tính phí thất bại
Kiểm tra và các bước tiếp theo
Tạo trong chế độ thử nghiệm
Sử dụng khóa API thử nghiệm của bạn để tạo đăng ký với
payment_link: true, sau đó mở liên kết và hoàn thành mệnh lệnh.Kích hoạt một khoản phí
Gọi điểm cuối tính phí với một
product_price nhỏ (ví dụ: 100) và xác minh rằng bạn nhận được payment.succeeded.Khắc phục sự cố
- 422 Yêu cầu không hợp lệ: Đảm bảo
on_demand.mandate_onlyđược cung cấp khi tạo vàproduct_priceđược cung cấp cho các khoản phí. - Lỗi tiền tệ: Nếu bạn ghi đè
product_currency, xác nhận rằng nó được hỗ trợ cho tài khoản và khách hàng của bạn. - Không nhận được webhook: Xác minh URL webhook và cấu hình bí mật chữ ký.