概述游戏内支付系统旨在为开发者提供一种方式，让他们能够轻松地向用户销售任何产品，而无需用户离开游戏。所售产品完全由商店决定，可以是游戏内物品（如武器或弹药）、游戏内货币（如硬币或金钱），甚至是玩家角色的服装。您可以选择任意数量的游戏内产品，并单独或成捆出售这些产品。对产品类型或销售方式没有任何限制，也没有禁止任何其他游戏内销售机制。该系统的目的是将用户通常熟悉的平台支付体验带到您的游戏中，让用户更轻松地从钱包中花钱购买您的产品。通过这种集成，您的游戏可以立即接触到更多用户，并支持更广泛的可用支付方式。
使用此系统，您可以完全控制购买过程。每次成功响应购买请求都可确保用户安全扣款，并且您会收到可靠且及时的通知。成功购买后，您将负责管理所售商品。例如，对于限时商品，商品的到期日期将由您的系统确定。
除了游戏内购买之外，该系统还为您的财务和客户服务系统提供附加功能：
当客户付款失败时，您将收到通知。
您可以通过网络服务提供退款并检查交易状态。
您可以通过我们的合作伙伴网站实时查看有关商品和游戏销售的详细报告。游戏内购买的最佳实践如果您计划在游戏中使用游戏内购买，我们准备了一些建议、最佳实践和资源来帮助您做好准备。无论是免费游戏还是付费游戏，只要它有游戏内购买，在发布之前都有一些共同的要点值得考虑。
请参阅微交易（游戏内购买）文档，了解有关游戏内经济和最佳实践的更多建议。支付系统如何运作支付系统结合了您的游戏内购买流程、计费网络服务和客户评论流程。
购买流程将按以下顺序进行。您的用户将始终在您的游戏内开始和完成订单。
当您的客户希望进行游戏内购买时，游戏会向您的购买服务器发送购买请求。购买服务器可以是您的游戏系统用来处理购买请求的任何服务实体。这可以是 Web 服务器或您的身份验证系统。此服务器必须通过 HTTP 与计费服务器通信。此外，您的购买服务器可以从计费服务器请求用户的国家/地区、语言和货币，并相应地调整定价。
接下来，您的购买服务器将代表客户向 Web 服务发起付款交易。此请求将通过安全的 HTTP POST 传递。此请求的内容包括用户元数据、描述以及用户希望购买的每件商品的价格。
收到请求后，会自动激活覆盖层，显示一个对话框，其中列出了所有商品和价格，以及确认或授权交易的按钮。如果用户的账户余额不足，覆盖层会引导用户进行充值。覆盖层将收集并处理用户的所有账单信息。完成后，用户将收到购买授权成功或失败的通知。您的游戏必须设置回调来接收此通知并将结果传递给购买服务器。
当您的购买服务器收到通知时，它会发送一个调用来完成操作。成功响应后，用户将被收费，然后您就可以向用户授予商品。
或者，如果您的游戏已经通过网络销售商品，或者您想在自己的网站上提供它作为付款方式，您可以选择基于浏览器的集成。如果您使用此方法，购买过程将按以下顺序进行：
用户希望在您的网站或游戏内进行购买。如果在游戏内，您必须启动浏览器才能打开您的网站。
您的购买服务器将使用安全的 HTTP POST 代表用户发起网络交易。如果成功，它将返回一个唯一的 URL，您可以将用户的浏览器会话重定向到该 URL 以授权交易。重定向时，您需要指定用户在完成交易授权后返回的 URL。
一旦用户返回到您的站点，您的购买服务器将请求交易状态。如果授权成功，您可以拨打电话获取付款。 如何连接 先决条件 首先，创建发布者密钥。有关详细说明，请参阅使用 Web API 密钥授权文档。 此密钥将随所有 Web 服务器请求一起传递，并用于验证服务器请求。这应该作为 key= 参数与请求一起发送。 存储订单 将每个订单存储在您的系统中以供日后查询。使用唯一的 64 位订单 ID 查询交易。 提交请求 所有请求都必须通过 HTTP 1.1 GET 或 POST 发送，使用 TLS 加密连接。内容类型应为“/x-www-form-”，POST 参数应在请求正文中，使用标准 URL 编码格式。文本应使用 UTF-8 传输。
请求将通过此基本 URI 进行路由：
某些命令会返回通过或失败结果。如果返回失败结果，则会附加额外的错误代码和描述。如果响应成功，则不会出现这些代码。
响应默认以 JSON 格式返回，您可以通过在请求中添加“=xml”参数来选择使用 XML 格式。
注意：您必须实现灵活的 JSON 或 XML 方案才能以任意顺序发送和返回参数键。测试为您提供了一个开发人员沙盒，供您测试集成结果。沙盒支持常规 API 中可用的所有请求，但实际上不会从测试人员的钱包中扣除资金。
可以从另一个基本 URI 访问沙盒：
* 整合游戏内购买步骤
此方式适合有内置商店的游戏，用户会在游戏内进行购买。
可以通过以下API调用获取ID和语言：
要获取用户的国家和货币类型，请使用传入用户 ID 的 Web API 请求。
该用户的元数据应与您的一般购买数据一起发送到购买服务器。
第三步
您的购买服务器通过 Web 服务代表客户端发起购买请求。您需要使用下面描述的方法。请求必须包含以下数据：
如果交易被接受，系统将自动通知客户授权购买。如果返回错误，您需要纠正问题并重新提交购买交易。
第四步
如果尝试成功，游戏内界面会通知用户需要授权交易。显示的交易详情将使用购买请求中提供的物品描述。然后用户可以授权交易。如果用户的账户余额不足，系统会自动引导用户充值。最后，您的游戏会收到交易是否授权成功的通知。
您的游戏需要设置一个回调处理程序来接收授权是否成功的通知。此回调结果包含、以及交易的授权状态。您的游戏可以将此结果发送到购买服务器以最终确认交易。有关更多信息，请参阅文档。
第五步
您的购买服务器将使用API命令，使用以下参数来完成交易。
成功响应表示购买被接受，物品应授予用户。错误响应表示交易无法完成，并将伴随相应的错误消息。
第 6 步
您的购买服务器需要频繁调用 API 来接收有关交易结算状态变化的通知。您应该每天至少调用一次此 API 来协调结算更新，但每分钟调用一次也可以，以确保您的服务器与交易更新保持同步。
您可以自行决定使用 API 退还客户交易。但是，您可能需要了解其他撤消交易的方法。当交易进入撤消状态时（例如， 、 、 aud 或 d - 请参阅 ），您的后端应尝试收回与撤消交易相关的项目（如果可能）。请查看我们的文档，并确保您已采取措施防止最常见的欺诈类型。基于 Web 的购买如果您的游戏商店托管在网络上，或者您只是想添加付款作为付款方式，您可以按照以下步骤进行集成：
注意：我们建议您将用户的游戏帐户链接到他们的ID，以便用户只需进行一次此二次登录。
第2步
调用 Web API，传入用户的 ID，并获取用户的国家/地区和货币类型。此数据可用于在您的商店中为用户显示适当的定价和货币。
注意：有一个可选的 IP 地址参数可用于指示用户的原始位置。每次在网页上进行购买或用户不使用客户端登录游戏时，都会发送用户的公共 IP 地址。
第三步
您的购买服务器使用 通过 Web 服务发起购买请求。除了常规游戏内购买所需的数据外，还需要另外两部分数据：
当设置为 WEB 时，请求将返回一个附加参数。这是一个唯一的 URL，用于重定向用户的 Web 会话并标识此 API 调用建立的交易。
第四步
您的购买服务器会将用户的 Web 会话重定向到 API 调用返回的 URL。重定向时，您需要附加自己的 URL，以便在交易成功（或被拒绝）时将用户返回到该 URL。您必须指定完整的 URL（例如 ）并使用
=
格式。
当用户被重定向到 URL 时，他们必须先登录才能进行身份验证。如果用户选择在您的网站上使用付款，他们将期望看到此步骤。但是，如果用户通过登录玩您的游戏，最好跳过第二次登录。这可以使用游戏内覆盖的内置 Web 浏览器功能来完成。当使用游戏内覆盖浏览器进行授权时，用户会自动登录。使用 API
调用来启动浏览器。
请参阅此处了解有关使用游戏内覆盖的详细信息。
第五步
用户返回您的网站后，进行 API 调用以获取结果。如果订单状态为“（已批准），则调用 API 收取付款。如果返回任何其他状态，则终止交易。
注意：如果用户中途关闭浏览器，或者发生任何意外情况导致用户无法返回您的网站，请终止交易并且不要拨打电话。即使用户批准交易但由于某种原因没有被引导回来，也必须终止交易并重新启动。
第 6 步
您的购买服务器需要频繁调用 API 来接收有关交易结算状态变化的通知。您应该每天至少调用一次此 API 来协调结算更新，但每分钟调用一次也可以，以确保您的服务器与交易更新保持同步。
您可以自行决定使用 API 退还客户交易。但是，还有其他方法可以撤销交易，您可能需要注意。当交易进入撤销状态时（例如， 、 、 aud 或 d - 请参阅 ），您的后端应尝试收回与撤销交易相关的项目（如果可能）。请查看我们的文献，并确保您已采取措施防范最常见的欺诈类型。附录 A：状态值以下是 Web API 可能返回的状态值。具有这些值的响应键通常称为 。
附录B：错误代码 以下是Web API可能返回的错误代码。一般调用这些值的响应键。
还有其他问题吗？如果您有任何疑问，请访问游戏内购买讨论论坛。