Chuyển đến nội dung chính
Payment Retries tự động thử lại các khoản thanh toán gia hạn đăng ký thất bại theo lịch trình tăng dần. Khi một lần thử lại thành công, đăng ký sẽ được kích hoạt lại tự động — không cần hành động của khách hàng hoặc công việc tích hợp.

Payment Retries Là Gì?

Khi một khoản thanh toán gia hạn đăng ký thất bại, đăng ký sẽ được đặt tạm ngưng. Với Payment Retries được kích hoạt, Dodo Payments sẽ tự động tính lại phương thức thanh toán hiện có của khách hàng theo lịch trình thông minh cho đến khi thanh toán thành công hoặc cửa sổ khôi phục đóng lại. Điều này giúp thu hồi doanh thu mất mát do các lỗi tạm thời — thẻ hết hạn, không đủ tiền được nạp đầy, lỗi mạng tạm thời — mà không cần gửi email khách hàng hoặc yêu cầu họ cập nhật bất cứ điều gì.
Payment Retries chỉ áp dụng cho các khoản thanh toán gia hạn đăng ký. Các khoản thanh toán đầu tiên (thiết lập ủy quyền), khoản thanh toán một lần, phí thay đổi gói, và phí theo yêu cầu không được thử lại bởi tính năng này.

Cách Hoạt động của Payment Retries

1

Renewal fails

Một khoản thanh toán gia hạn đăng ký thất bại và đăng ký chuyển sang trạng thái on_hold.
2

Retryability check

Mã lỗi của lỗi được kiểm tra. Soft declines (không đủ tiền, từ chối chung, lỗi xử lý hoặc mạng, v.v.) có thể thử lại. Hard declines kết thúc chuỗi thử lại ngay lập tức, vì thử lại sẽ không thay đổi kết quả.
3

Scheduled retry

Nếu từ chối có thể thử lại và cửa sổ khôi phục cho phép, thử lại tiếp theo được lên lịch. Các lần thử lại tiến hành không trong phiên đối với phương thức thanh toán hiện có của khách hàng theo lịch trình tăng dần.
4

Recovery

Khi thử lại thành công đầu tiên, đăng ký trở lại trạng thái active và ngày thanh toán tiếp theo được nâng lên như bình thường. Nếu cửa sổ đóng lại trước khi thử lại nào thành công, việc thử lại dừng và đăng ký vẫn nằm ở trạng thái tạm ngưng.

Cấu hình Payment Retries

Kích hoạt và cấu hình Payment Retries từ Cài đặt → Khôi phục trong bảng điều khiển của bạn.
Trang Cài đặt Khôi phục với công tắc Enable Payment Retries bật và trường Recovery window (ngày) được đặt thành 13
Cài đặtMô tảMặc định
Enable Payment RetriesTự động thử lại các khoản thanh toán gia hạn đăng ký thất bại để thu hồi doanh thu.Tắt (đăng ký)
Cửa sổ khôi phục (ngày)Thời gian thử lại một khoản thanh toán thất bại trước khi từ bỏ. Phải nằm trong khoảng từ 1 đến 30.13
Cửa sổ khôi phục được gắn với thời gian hóa đơn gia hạn thất bại được tạo. Các lần thử lại chỉ được lên lịch trong khi tổng thời gian trì hoãn vẫn nằm trong cửa sổ.

Lịch trình Thử lại

Thử lại tiến hành lùi dần. Tối đa 8 lần thử được thực hiện, miễn là mỗi lần đều nằm trong cửa sổ khôi phục của bạn:
Lần thửTrì hoãn sau lần thử trướcThời gian ước tính kể từ khi thất bại
112 giờ12 giờ
224 giờ36 giờ
348 giờ~3.5 ngày
472 giờ~6.5 ngày
596 giờ~10.5 ngày
6120 giờ~15.5 ngày
77 ngày~22.5 ngày
87 ngày~29.5 ngày
Một cửa sổ khôi phục 13 ngày (mặc định) bao gồm các lần thử 1 đến 5 (lần thử 5 bắn ra ~10.5 ngày sau khi thất bại). Tăng cửa sổ về phía tối đa 30 ngày nếu bạn muốn các lần thử sau, với khoảng cách rộng hơn (6 đến 8) chạy.

Chuyển đổi Trạng thái Đăng ký

Sự kiệnTrạng thái đăng ký
Gia hạn thanh toán thất bạiactiveon_hold
Thử lại thất bạigiữ nguyên on_hold (lịch thử lại tiếp theo nếu cửa sổ cho phép)
Thử lại thành côngon_holdactive, ngày thanh toán tiếp theo được cập nhật
Cửa sổ khôi phục hết hạngiữ nguyên on_hold
Đăng ký bị hủycác lần thử lại được lên lịch dừng ngay lập tức (kết thúc — không có thêm thử lại nào)
Nếu một đăng ký bị hủy trong khi các lần thử lại vẫn đang được lên lịch, chuỗi thử lại sẽ kết thúc ngay lập tức và không có thêm nỗ lực nào được thực hiện. Các trạng thái không hoạt động khác (on_hold, expired, pending, failed) tiếp tục thử lại, vì hóa đơn gia hạn mở của chúng đại diện cho khoản nợ cho các khoảng thời gian mà khách hàng đã tiêu thụ.
Những chuyển đổi này phát ra các sự kiện webhook đăng ký tiêu chuẩn, vì vậy bạn có thể sử dụng logic quyền từ chúng mà không cần xử lý thử lại đặc biệt:
Sự kiệnPhát khi
subscription.on_holdGia hạn thất bại và đăng ký bị tạm dừng
subscription.activeThử lại thành công và đăng ký được kích hoạt lại

Subscription Webhook Payloads

Xem các schema tải dữ liệu webhook đầy đủ cho các sự kiện vòng đời đăng ký.

Thất bại có thể thử lại và không thể thử lại

Loại thất bạiVí dụThử lại?
Từ chối mềmKhông đủ tiền, từ chối chung, vượt quá tốc độ thẻ, lỗi xử lý, lỗi mạng / hết thời gian, thử lại sau
Từ chối cứngThẻ bị mất/cướp, thẻ không hợp lệ, không chấp nhận, tài khoản đã đóng và các từ chối kết thúc khácKhông — chuỗi kết thúc ngay lập tức
Thử lại từ chối cứng sẽ không thay đổi kết quả, vì vậy chuỗi thử lại kết thúc ngay khi có từ chối cứng. Kết hợp Thử Lại Thanh Toán với Subscription Dunning để thúc đẩy khách hàng cập nhật phương thức thanh toán của họ trong các trường hợp đó.

Thử Lại Thanh Toán và Dunning

Thử Lại Thanh Toán và Subscription Dunning là công cụ khôi phục bổ trợ:
Thử Lại Thanh ToánSubscription Dunning
Cơ chếÂm thầm sạc lại phương thức thanh toán hiện cóGửi email cho khách hàng để cập nhật phương thức thanh toán
Hành động của khách hàngKhông cần thiếtKhách hàng cập nhật phương thức thanh toán trong cổng thông tin
Thích hợp choTừ chối mềm/tạm thời tự khắc phụcThẻ hết hạn hoặc không hợp lệ cần thay thế
Bật cả hai cho phép bạn có phạm vi khôi phục rộng nhất: thử lại tự động bắt lỗi tạm thời, trong khi dunning mang lại cho khách hàng có phương thức thanh toán cần thực sự cập nhật.

Liên quan

Subscription Dunning

Chuỗi email thúc đẩy khách hàng cập nhật phương thức thanh toán của họ.

Abandoned Cart Recovery

Khôi phục các thanh toán một lần không hoàn thành hoặc thất bại với email nhắm mục tiêu.

Subscriptions

Hiểu các trạng thái đăng ký có liên quan trong các luồng khôi phục.

Subscription Webhooks

Phản hồi các sự kiện subscription.on_holdsubscription.active.
Lần sửa đổi cuối 26 tháng 6, 2026