用于复杂定制数字商品的Google推荐流程

Question

我试图建立一个谷歌钱包支付程序，让用户购买一个条目进入一个锦标赛。为了做到这一点，用户必须填写一堆关于自己的信息(姓名、联赛球员号码、联系人电话号码等)，还有其他一些隐含的数据，例如他们要进入的锦标赛的唯一标识符。

在Google中，似乎有两种方法可以实现这一点，我想知道我是否缺少另一种更好的工作流和/或这两种方式中的一种更好。

可能性#1

当用户单击“钱包”按钮时，我会序列化表单并使用ajax将其提交给服务器。如果表单被正确填写，服务器将表单的所有内容编码到JWT的sellerData字段中，并异步返回JWT。然后，我将这个JWT传递给皮夹，期望在我的回发处理程序中收到它。

然后，回发处理程序使用JWT sellerData字段中的信息构造条目，并将其记录在数据库中。

这种可能性对我来说是直观的，我已经实现了，但是我遇到了sellerData字段的200个字符限制，因为它包含多个人的名字、电话号码和其他各种表单元素。只是没有空间了。我没有办法解决这个问题，我欢迎你的想法。

这种方法的优点是在支付成功之前我的数据库中不创建任何东西，但我不知道如何解决在JWT中表示整个表单的困难，以便将其以某种方式传递给回发处理程序。

可能性#2

用户只是使用正常的web表单提交过程提交条目表单，这会在数据库中创建一些内容。以这种方式新创建的数据库对象被标记为“未支付”，因此是不完整的。

一旦用户成功地在数据库中创建了他们的条目，他们就会看到第二个页面，他们可以在其中付费。这样做更好，因为我现在可以将他们刚刚创建的对象的数据库键放到sellerData字段中，而不必担心大小限制。

它确实有一个不幸的副作用，就是将这些半完成的对象保存在数据库中，并冒着用户无法完全理解注册和付费两步流程的风险，而忘记支付。我必须非常小心和积极地确保用户意识到A)在没有支付信息的情况下提交表单是可以的，而B)提交第一份表单并不意味着他们已经完成了。

有什么想法？

Answer 1

我认为选项2是一个相当标准的买入流程。第一步输入你的信息，第二步确认你的信息并用钱包付款。

onsuccess回调可以将用户重定向到购买收据页面。

我的消费者意识没有看到任何购买流程的危险信号。

Answer 2

最后我选择了选项2，因为它对我来说是最简单的，而且我不认为它会混淆用户。

不过，我错过了第三种选择，那就是我可以让人们购买一张空白的报名表，然后在购买后填写。我认为这可能会更好；它更符合在人的购买经验，因此会更熟悉的购买者，它避免了问题的人，他们认为他们已经注册，但不知怎么没有意识到他们必须支付。