结账实践——PHP

发布于 2024-08-18 06:13:15 字数 407 浏览 2 评论 0原文

我正在使用 FirstData Global Gateway API 为客户端编写结帐模块的最后阶段。用于数据输入的所有表单视图均已创建,并且控制器已成功与 FirstData Web 服务通信测试数据。

我正在寻找有关如何在单击“处理订单”按钮后构建结账用户体验的最佳实践的想法。

我计划使用 javascript 在单击进程按钮后禁用该按钮,并在此延迟期间将信息传递到 Web 服务。您过去可能使用过哪些方法来造成这种延迟,同时通知用户正在拨打付款电话。您过去可能使用过哪些方法来最好地操作通知交易是否已被批准或拒绝的回调函数?有没有人发现使用 PHP_SELF 在同一个脚本中处理所有这些信息来执行操作,或者通常最好将此逻辑放在其他地方?

只是一些一般性的询问,通过一些尝试和错误来帮助指导整个过程。也许回复会有助于收集一些不错的想法供大家使用。

I am in the process of writing the final stages of a checkout module using the FirstData Global Gateway API for a client. All the form views for data entry have been created and the controllers are successfully communicating test data with the FirstData webservice.

I am looking for thoughts on best practices on how to structure the user experience for checkout after the 'process order' button is clicked.

I am planning on using javascript to disable the process button after it is clicked and have the information passed to the Web Service during this delay. What are some methods you may have used in the past to create this delay while informing the user that the payment call is being made. What are some methods you may have used in the past to best operate the callback function that notifies if the transaction has been approved or declined? Has anyone found processing all this information in the same script using PHP_SELF for the action, or is it generally better to place this logic elsewhere?

Just some general inquires to help guide the process through a little trial and error. Maybe the response will help collect some pretty good thoughts for everyone's use.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

凉城凉梦凉人心 2024-08-25 06:13:15

您可能有哪些方法
过去用于创建此延迟
同时告知用户
正在拨打付款电话?

您不想延迟任何流程,因为处理付款会产生足够的开销,导致自然延迟发生。您此时的目标是防止重复提交,并让用户知道在等待时发生了一些事情。禁用提交按钮是个好主意。此外,为结帐流程创建一个唯一的密钥(也需要与订单一起提交)是一个好主意。当他们提交付款时,您检查该密钥并确保它在那里(通常位于会话变量中)。如果删除它然后处理交易,如果他们再次提交表单,则可以将其标记为重复交易。

您可能有哪些方法
过去用来最好地操作
回调函数,通知如果
交易已获批准或
拒绝?

支付网关将返回批准、拒绝或错误值。没什么花哨的,所以实际上不需要花哨的处理。批准的交易应执行所有相关订单和数据库信息操作,然后用户应进入感谢/收据页面。错误和拒绝可以通过类似的方式处理,并再次向用户呈现结帐页面。如果该卡被拒绝,请礼貌地告知用户他们的银行拒绝了该交易,并邀请他们使用其他信用卡。如果出现处理错误,您可以要求他们重试或指示他们通过电话与您联系以下订单。

有没有人发现处理这一切
使用同一脚本中的信息
PHP_SELF 为动作,或者是
通常更好地放置这个逻辑
其他地方?

西红柿,西红柿。这完全取决于您的编程风格。将付款流程与表格放在同一页面上就可以了。我已经做到了。重要的是付款处理得当并且用户看到他们需要看到的内容。后台发生的事情对他们来说并不重要。

What are some methods you may have
used in the past to create this delay
while informing the user that the
payment call is being made?

You don't want to delay the process any as processing the payment will incur enough overhead for natural delay to occur by itself. Your goal at this point to prevent duplicate submissions and let the user know something is happening while they wait. Disabling the submit button is a good idea. Also, creating a unique key for that checkout process that also needs to be submitted with the order is a good idea. When they submit their payment you check for that key and make sure it is there (usually it is in a session variable). If it is delete it and then process the transaction, if they submit the form again it will then be able to be flagged as a duplicate transaction.

What are some methods you may have
used in the past to best operate the
callback function that notifies if the
transaction has been approved or
declined?

The payment gateway is going to return an approved, declined, or error value. Nothing fancy so there's really no fancy handling required. Approved transaction should have all relevant order and database information actions performed and then the user should be taken to a thank you/receipt page. Errors and declines can be handled in a similar ways with the user being presented with the checkout page again. If the card is declined let the user know politely that their bank declined the transaction and invite them to use a different credit card. If there is a processing error you can either ask them to try again or direct them to contact you by telephone to place their order.

Has anyone found processing all this
information in the same script using
PHP_SELF for the action, or is it
generally better to place this logic
elsewhere?

Tomato, tomáto. It all depends on your programming style. Having the payment process on the same page as the form is fine. I've done it. All that matters is that the payment is handled properly and the user sees what they need to see. What happens in the background doesn't matter to them.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文