用户关闭支付浏览器怎么办？

Posted 2023-02-22

【中文标题】用户关闭支付浏览器怎么办？

【英文标题】：What to do when user closes payment browser?

【发布时间】：2020-05-19 05:50:08

【问题描述】：

在我正在开发的 android 应用中，我们遇到了付款问题。

当用户想要下订单时，我们会执行一个 API 请求，该请求将返回一个支付 URL 和一个支付 ID。 URL 是我们将为支付打开的网页，ID 用于从我们的 API 中检索支付状态。当我们从 API 请求付款状态时，它会返回“成功”、“已取消”或“待处理”。当支付完成或用户点击支付网页内的取消链接时，用户将被重定向到应用程序处理的 URL。如果用户被重定向，我们将进入订单确认页面（支付成功时）或返回结账页面（点击网页中的取消链接取消支付时）。付款网页使用 Chrome 自定义选项卡打开。

当用户在完成或取消支付之前关闭浏览器然后返回我们的应用程序时会出现此问题。当用户在没有被浏览器重定向的情况下返回我们的应用程序时，应用程序会发出一个状态请求来检查我们是否应该进入订单确认页面。当浏览器关闭时，可能会出现以下情况之一：

用户已付款但在重定向发生前关闭了浏览器。状态请求将返回“成功”，我们可以进入订单确认屏幕。 用户尚未支付，点击支付页面中的取消按钮，但在重定向发生前关闭了浏览器。状态请求将返回“已取消”，我们可以将用户返回到结帐屏幕。 用户已付款，但付款仍在处理中。用户关闭浏览器并返回应用程序。状态请求将返回“待处理” 用户不想付款，只是关闭了浏览器，因为他想返回结帐页面更改表单中的某些内容，状态请求将返回“待处理”，因为 API 不知道用户关闭了浏览器

场景 1 和 2 非常好，但 3 和 4 会导致问题。当状态请求返回“待处理”时，应用程序不知道是场景 3 还是 4。应用程序将在结帐屏幕顶部显示“付款待处理”的对话框。问题是，当这种情况发生时，应用程序不知道是否 1) 付款仍在处理中并且将来某个时间会成功，或者 2) 永远不会成功，因为用户从未付款。如果用户关闭这个对话框，仍然有可能支付成功，用户不知道。我们收到了很多用户投诉，他们关闭了此对话，然后再次尝试下单，导致意外重复下单。

我们尝试了一些解决方法，让对话在至少 30 秒内不可关闭，以便有一些时间来处理付款，但这会给刚刚关闭对话以返回结帐屏幕的用户带来非常糟糕的用户体验（场景4）。

我们是否缺少任何可以解决问题的 Android 功能？还有其他解决方案吗？我们希望看到其他应用程序的方法。

【问题讨论】：

支付提供商是否有任何 API 可以检查支付状态或确认您的支付？您能否分享有关您的支付提供商工作流程的更多详细信息？

我们的后端有一个端点，通过发送支付 ID 来检查支付状态。它可以返回成功、挂起或取消。

从支付提供商端完成支付状态需要多长时间？

您是 PSP 还是将用户重定向到您在其中拥有帐户的 PSP？换句话说，PSP还是PSP用户？

@MirMiladHosseiny 它可能需要 X 时间，通常是即时的，但并非适用于所有付款方式。

【参考方案1】：

这就是我的处理方式：

在用户选择产品或产品后，您应该为这些产品创建一个订单实体，并在此级别为订单提供一个 ID并且在更改后您正在为其创建新订单）将付款ID分配给订单，当用户想要支付订单时检查订单的最后付款ID并指定订单的付款状态。 如果有可能在用户支付订单之后和浏览器重定向到应用程序之前，用户会关闭浏览器，这不是问题，因为在用户返回应用程序的订单活动后，我们已经存储了当前订单的最后一个支付 ID，并且我们可以检查付款状态并根据该状态采取行动，如果订单处于待处理状态（假设付款服务需要 30 分钟来进行付款处理并指定付款成功或失败），我们可以告诉用户并给它取消付款的选项，如果这笔钱被转换为取消的付款，我们应该退还这笔钱（这不应该发生，因为您已经使用支付服务检查了支付状态并且它处于待处理状态并且您对支付服务说应该取消待付款）给用户，我们也应该取消订单。

如果您有其他场景或此场景中的一些错误，请告诉我找到解决方案

【参考方案2】：

嗯，该解决方案高度依赖于您使用的支付提供商，尽管所有主要的支付提供商都有方法在其 API/SDK 中内置处理它。

最正确的做法是不要依赖重定向，因为由于您刚才提到的原因，这通常是一个坏主意。我建议在支付提供商端和您的后端使用一些 webhook 和套接字系统。

如果支付提供商没有针对所需事件的挂钩，我将创建一个循环作业，以使用 Android 客户端提供的 paymentId 来检查支付提供商 API 的支付状态。仅当付款待处理时，该作业才会处于活动状态。当状态发生变化时，最好在后端和客户端都实现套接字以通知客户端有关更改而无需在客户端上重复执行一项工作。

如果支付提供商有检查支付状态所需的 webhook - 使用它而不是重复工作。

如果没有提供 paymentId - 跟踪特定用户的所有待付款。

在这种情况下，Android UI 的变化将是最小的——一些关于状态更新的信息，也许还有花哨的加载器。应该实现套接字，但要根据更改的值进行一些数据存储和 UI 的响应式刷新。

由于这是一个关于 Android 的问题，我会推荐一些 Android 技术人员在 Android 客户端上处理它。所以 - 用于套接字的 Socket.io、Room 或一些反应式 sharedpref（甚至 android 本机也可以）来存储数据，LiveData 来更新 UI。

这就是我的工作方式，也是我将来实施的方式。这可能并不理想，但将所有与支付相关的主要内容移至后端是个好主意。

对于此类组合错误和错误也可能有一些特定的 - 但每种方法都会有一些。

希望这个答案对你有所帮助。

【讨论】：

老实说，这并没有真正的帮助。问题是，当我获得“待处理”状态时，我的应用无法区分“关闭浏览器”和“付款处理”状态，因为它们都会显示为“待处理”。

虽然应用程序无法做到这一点（它可能知道，但在黑客的帮助下），支付提供商可能知道 - 从中​​获取此信息。

【参考方案3】：

尝试使用 Api 处理，这对您来说是更好的解决方案。

Step1：当您收到付款状态（成功/取消/待定）时，将用户状态存储在您的数据库中

现在，如果任何用户尝试关闭浏览器，但最后的交易状态已保存在您的数据库中。

第2步：然后尝试通过在android的onresume方法中调用您的api来获取用户订单状态。

那时你肯定得到了准确的付款状态，因为它已经保存在你的数据库中了。

所以当你不小心或其他原因关闭浏览器时。他将重定向到您的应用程序，并且有时会调用您的 on resume 应用程序方法，他将看到应用程序的正确状态。

注意：我们在 CCAvenue 支付网关中也是如此。在他们的支付网关中，我们编写了重定向 URl 和取消 URL 方法以存储支付状态的代码。