Hướng dẫn về phê duyệt trước và hoàn tiền khi sạc xe điện

1. Tại sao việc sạc xe điện đôi khi sử dụng biện pháp giữ thanh toán

Khi bắt đầu một phiên sạc, nhà mạng có thể không biết lượng năng lượng cuối cùng được cung cấp hoặc thời gian sạc. Ủy quyền trước là một cách để kiểm tra xem có đủ tiền trong tài khoản trước khi cung cấp dịch vụ với tổng chi phí thay đổi. Đây không phải là mô hình duy nhất: ví điện tử, số dư trả trước và thanh toán qua tài khoản tuân theo các quy trình khác nhau.

Số tiền ủy quyền cần phản ánh chính sách thương mại đã được ghi nhận. Mức giữ tiền quá cao có thể gây khó chịu cho tài xế, trong khi số tiền quá thấp so với phiên giao dịch dự kiến có thể tạo ra rủi ro thu hồi nợ. Cách tiếp cận phù hợp phụ thuộc vào đối tượng người dùng, nhà cung cấp thanh toán, phiên giao dịch trung bình và các tùy chọn thu thập dữ liệu được hỗ trợ.

Để hiểu rõ sự khác biệt cơ bản, xem Tài liệu của Stripe về việc tách biệt ủy quyền và thu phí.Tài liệu đó mô tả các phương thức hợp lệ và thời hạn hiệu lực của ủy quyền. Điều đó không có nghĩa là mọi cổng thanh toán hoặc phương thức thanh toán địa phương đều sử dụng cùng một quy tắc.

2. Tách biệt các quy trình ủy quyền, thu thập thông tin, hủy bỏ và hoàn tiền.

Những điều khoản này rất quan trọng vì hành động tiếp theo phụ thuộc vào trạng thái hiện tại. Một phiên giao dịch chưa bắt đầu có thể cần hủy ủy quyền. Một phiên giao dịch đã hoàn tất và được ghi nhận nhưng phí không chính xác có thể cần hoàn lại một phần. Việc gọi cả hai trường hợp là "đã hoàn tiền" khiến tài xế thắc mắc tại sao sao kê ngân hàng của họ lại khác nhau.

Trạng thái thanh toán cũng cần được tách biệt với trạng thái tính phí. "Tính phí hoàn tất" không chứng minh rằng việc thu tiền đã thành công, và "thanh toán được ủy quyền" không chứng minh rằng điện đã được cung cấp. Hồ sơ của bạn cần liên kết cả hai quy trình mà không coi chúng là cùng một sự kiện.

3. Thiết kế quy trình phiên thông thường

Trước khi thanh toán, hãy hiển thị rõ ràng bảng giá, bất kỳ khoản phí bổ sung nào và khoản tiền tạm giữ dự kiến. Giải thích rằng việc ủy quyền chỉ là tạm thời và khoản phí cuối cùng phụ thuộc vào phiên sử dụng. Đặt thông tin này ở nơi tài xế đưa ra quyết định thanh toán, chứ không chỉ trên một trang điều khoản dài dòng.

Sau khi được ủy quyền, yêu cầu bắt đầu tính phí và chờ bằng chứng thích hợp từ phía người sạc. Lưu lại mã định danh phiên và mã tham chiếu thanh toán. Nếu người sạc không bắt đầu tính phí theo quy trình đã thỏa thuận, hãy hiển thị trạng thái cần thiết và thực hiện quy trình hủy hoặc điều tra đã được xác định.

Khi phiên làm việc kết thúc, hãy tính phí dựa trên dữ liệu đã ghi lại và biểu giá áp dụng. Gửi thao tác thu thập dữ liệu được hỗ trợ, ghi lại kết quả và xuất biên lai với số tiền cuối cùng. Biên lai cần xác định rõ trang web, trình kết nối, khoảng thời gian, số lượng tính phí và tuyến hỗ trợ.

Trong một ví dụ đơn giản, người vận hành ủy quyền $30 và phí phiên được xác minh là $8.40. Nếu nhà cung cấp hỗ trợ quy trình thu hộ một phần đã thỏa thuận, hệ thống sẽ thu $8.40 và xử lý phần ủy quyền chưa sử dụng theo quy tắc của nhà cung cấp. Đây chỉ là một giao dịch minh họa, không phải là số tiền giữ lại được khuyến nghị.

4. Xác định điều gì xảy ra khi hành trình bị gián đoạn

Hãy xem xét trường hợp ủy quyền thành công nhưng bộ sạc từ chối yêu cầu bắt đầu. Nền tảng không nên hiểu việc phê duyệt thanh toán là dịch vụ tính phí đã hoàn tất. Nền tảng cần liên kết việc bắt đầu không thành công với khoản thanh toán liên quan và tuân theo chính sách hủy bỏ đã được ghi lại.

Một trường hợp phổ biến khác là kết nối bị gián đoạn vào cuối quá trình tính phí. Giá trị công tơ cuối cùng có thể đến muộn hơn so với dự kiến của quy trình thanh toán. Hãy xác định cách hệ thống chờ đợi, thử lại hoặc chuyển tiếp mà không cần tự ý đưa ra một con số cuối cùng. Nếu có thể khôi phục dữ liệu cục bộ, hãy sử dụng bằng chứng đó thông qua quy trình đối chiếu đã được thỏa thuận.

Một phiên giao dịch cũng có thể tốn nhiều chi phí hơn so với lần ủy quyền ban đầu. Đừng cho rằng nền tảng có thể tự động thu bất kỳ khoản tiền lớn nào. Có thể cần thêm ủy quyền, ủy quyền tăng dần hoặc phương pháp thu tiền khác, tùy thuộc vào sự hỗ trợ của nhà cung cấp và thiết lập thương mại. Hãy quyết định điều này trước khi triển khai.

Nếu quyền ủy quyền hết hạn trước khi thu thập dữ liệu, hãy xử lý nó như một trường hợp ngoại lệ cụ thể có người chịu trách nhiệm. Thời hạn hiệu lực được hỗ trợ khác nhau, vì vậy việc tích hợp nên sử dụng trạng thái thanh toán và thông tin hết hạn của nhà cung cấp thay vì một thời hạn cố định chung.

5. Cung cấp quy trình hoàn tiền riêng biệt và có thể kiểm toán được.

Quy trình hoàn tiền bắt đầu từ khoản thanh toán đã được thu. Người vận hành cần lý do, số tiền đã được phê duyệt và liên kết đến giao dịch gốc. Hệ thống cần ghi lại người yêu cầu, người phê duyệt (nếu cần) và liệu nhà cung cấp đã chấp nhận, hoàn tất hay từ chối yêu cầu.

Hoàn tiền một phần rất hữu ích khi chỉ cần điều chỉnh một phần phí. Ví dụ, phí năng lượng có thể hợp lệ nhưng phí chờ không sử dụng cần được hoàn trả. Hãy giữ lại biên lai gốc và ghi lại khoản điều chỉnh thay vì âm thầm ghi đè lịch sử giao dịch.

Tài liệu hoàn tiền của Stripe Phân biệt việc hủy các khoản thanh toán chưa hoàn tất với việc hoàn tiền cho các khoản thanh toán thành công và mô tả các kết quả đang chờ xử lý hoặc thất bại. Xây dựng các quy trình hỗ trợ dựa trên tình trạng thực tế của nhà cung cấp. Yêu cầu hoàn tiền đã gửi không nên tự động trở thành một thông báo đảm bảo rằng tiền đã đến tay người lái xe.

Tránh hứa hẹn thời gian phát hành hoặc hoàn tiền cố định trừ khi điều kiện của nhà cung cấp và ngân hàng phát hành cho phép. Giải thích những gì hệ thống của bạn đã thực hiện và cung cấp cho khách hàng mã tham chiếu thanh toán để theo dõi.

6. Đảm bảo khả năng chống chịu của hệ thống tích hợp trước các sự kiện lặp lại hoặc bị trì hoãn.

Thông báo thanh toán là một phần của thiết kế vận hành, chứ không phải là khâu xử lý nền. Tài xế có thể đóng trình duyệt, kết nối di động có thể bị gián đoạn, và nhà cung cấp dịch vụ thanh toán có thể gửi sự kiện sau khi màn hình tính phí đã ngừng cập nhật. Hệ thống phụ trợ vẫn cần đạt được trạng thái tài chính chính xác.

Sử dụng thông báo từ nhà cung cấp đã được xác minh và kiểm tra đối tượng thanh toán hiện tại khi cần thiết. Ghi lại mã định danh sự kiện, bảo vệ các hành động khỏi việc xử lý trùng lặp và tính đến các sự kiện đến không theo trình tự. Thông báo lặp lại không được tạo ra lần thu tiền hoặc hoàn tiền thứ hai.

Tài liệu về webhook của Stripe Bài viết này giải thích về việc xử lý sự kiện bất đồng bộ, xác minh chữ ký và các vấn đề liên quan đến việc gửi thông báo. Việc triển khai của bạn cần tuân theo các yêu cầu của nhà cung cấp đã chọn. Về mặt vận hành, nhân viên cũng cần một hàng đợi các trường hợp chưa được giải quyết thay vì một bảng điều khiển màu xanh lá cây che giấu các thông báo bị thiếu.

Hiện tại Hướng dẫn tích hợp API sạc xe điện Cung cấp bối cảnh rộng hơn để kết nối nền tảng với các hệ thống thanh toán và kinh doanh. Xác định rõ ràng mô hình trạng thái thanh toán trong phạm vi dự án.

7. Đối chiếu hồ sơ phiên làm việc, thanh toán và quyết toán.

Việc xem xét lại hàng ngày hữu ích kết nối ba khía cạnh: những gì người sạc đã giao, số tiền tài xế phải trả và những gì nhà cung cấp báo cáo để thanh toán. Đối khớp các bản ghi bằng cách sử dụng các định danh ổn định, không chỉ dựa vào số tiền và thời gian ước tính. Hai tài xế khác nhau có thể dễ dàng có các phiên giao dịch với mức giá giống hệt nhau.

Đánh dấu các phiên chưa thanh toán hoàn tất, các khoản thanh toán không tương ứng với phiên, các giao dịch trùng lặp và các khoản hoàn tiền đang chờ xử lý. Phân công mỗi trường hợp ngoại lệ cho nhóm có thể điều tra. Bộ phận Tài chính cũng cần hiểu cách thức hiển thị phí nhà cung cấp và các điều chỉnh thanh toán.

Thanh toán trực tiếp bằng thẻ và thanh toán cước phí chuyển vùng là hai mối quan hệ khác nhau. Nếu tài xế tính phí thông qua nhà cung cấp dịch vụ di chuyển bên ngoài, việc đối chiếu thương mại có thể phụ thuộc vào hồ sơ và hóa đơn của đối tác. Để biết quy trình đó, hãy đọc thêm. Hướng dẫn về việc đối chiếu dữ liệu chuyển vùng từ bản ghi cuộc gọi (CDR) đến quá trình thanh toán. thay vì áp dụng quy trình thanh toán trực tiếp bằng thẻ mà không thay đổi gì.

8. Thử nghiệm các trường hợp gây khó chịu trước khi ra mắt.

Thực hiện các bài kiểm tra có kiểm soát đối với các trường hợp từ chối ủy quyền, ủy quyền thành công nhưng khởi động thất bại, thu thập một phần thông thường, các cuộc gọi lại trùng lặp, ghi lại phiên cuối cùng bị trì hoãn và ủy quyền hết hạn. Thêm các khoản hoàn tiền toàn phần và một phần, bao gồm cả khoản hoàn tiền đang chờ xử lý hoặc thất bại.

Trong mỗi trường hợp, hãy kiểm tra bốn điều: thông báo của trình điều khiển, trạng thái phiên tính phí, trạng thái thanh toán của nhà cung cấp và hồ sơ tài chính. Cả bốn điều này phải cho thấy một câu chuyện nhất quán. Một yêu cầu API thành công về mặt kỹ thuật vẫn có thể gây ra trải nghiệm khó hiểu cho khách hàng nếu cách diễn đạt mô tả sai sự kiện.

Hãy để nhân viên hỗ trợ luyện tập trước cách giải thích về khoản tiền bị tạm giữ. Họ cần có khả năng tìm thấy thông tin ủy quyền, khoản phí cuối cùng và số tham chiếu liên quan mà không cần yêu cầu khách hàng cung cấp thông tin ngân hàng không cần thiết.

Câu hỏi thường gặp

Việc thanh toán phí sạc xe điện có phải là một khoản phí phát sinh không?

Việc giữ tiền là để dự trữ tiền; nó không nhất thiết là một khoản phí đã hoàn tất. Tài xế nên kiểm tra xem số tiền đang chờ xử lý hay đã được thanh toán. Người điều hành nên cung cấp biên lai cuối cùng và điều tra bất kỳ sự chênh lệch nào giữa số tiền đã thu và phí phiên giao dịch đã được xác minh.

Liệu mọi phương thức thanh toán đều có thể sử dụng xác thực trước?

Không. Việc hỗ trợ phụ thuộc vào phương thức, nhà cung cấp, thiết lập của người bán và khu vực. Một số quy trình thanh toán cần mô hình trả trước, thanh toán ngay lập tức hoặc thanh toán qua tài khoản. Hãy xác nhận sự tích hợp thực tế trước khi quảng cáo một trải nghiệm thanh toán cụ thể.

Tại sao yêu cầu hoàn tiền lại có thể bị treo?

Kết quả phụ thuộc vào nhà cung cấp và trạng thái giao dịch, và việc hoàn tất có thể liên quan đến ngân hàng phát hành. Nhóm hỗ trợ nên phân biệt yêu cầu hoàn tiền với giao dịch hoàn tiền đã hoàn tất và sử dụng mã số tham chiếu của nhà cung cấp khi tiến hành điều tra.