Minecraft Web 面板余额系统和钱包交易指南

本指南包含在 PvPServer Minecraft Web 面板中。 平衡系统 和 钱包交易 它准备解释其结构。平衡系统；它允许玩家将资金上传到他们的网络面板帐户，使用加载的余额从市场购买产品，帐户的后付款余额，手动余额调整，退款或补偿交易以及检查交易历史记录。

1. 平衡系统有什么作用？

在 Minecraft Web 面板中，余额系统会在玩家的 Web 面板帐户中创建可用的虚拟钱包金额。玩家使用付款方式加载余额并使用该余额购买杂货。因此，玩家可以使用其帐户中的余额更快地购物，而不是每次购买产品时都返回支付提供商。

平衡系统专门与市场、支付、优惠券、订单和支持流程配合使用。当玩家加载余额时，如果支付成功，该金额就会添加到他的钱包中。当您从市场购买产品时，余额会减少该产品的价格。如果使用优惠券，则从余额中扣除折扣后的净额。如果产品未交付，订单和余额交易将一起审核。

余额系统用于以下交易：

• 使玩家能够为其帐户添加余额。
• 使用钱包余额作为杂货购物的支付方式。
• 付款后将交易成功反映至玩家账户。
• 从余额中扣除优惠券后的净额。
• 手动添加或扣除余额。
• 定义退款、补偿或活动余额。
• 检查玩家的余额历史记录。
• 通过准确的记录解决付款和市场支持请求。

2. 钱包逻辑

钱包是玩家网页面板帐户中的可用余额空间。玩家使用此余额购买 Minecraft 市场物品。钱包系统基于玩家帐户运行。因此，玩家使用正确的账号登录非常重要。

如果玩家使用错误的帐户登录，他的余额可能不会显示。例如，如果玩家使用电子邮件地址加载余额，然后使用另一个用户帐户登录，他可能会认为“我的余额尚未到达”。这种情况下实际上可能付款成功；但余额已添加到另一个帐户。

有关钱包系统的基本知识点：

• 余额取决于玩家的网络面板帐户。
• Minecraft 用户名和网络面板用户名可能不同。
• 余额可用于杂货购物。
• 当余额被花费时，应记录在交易历史中。
• 除非付款成功，否则余额不会自动添加。
• 必须记录手动余额交易。

3. 余额充值流程如何进行？

余额充值过程中，玩家登录网页版账户，进入余额充值页面，选择或输入金额，选择支付方式，完成支付流程。当支付提供商成功退货时，系统会将相关金额添加到玩家的钱包中。

一般余额充值流程如下：

1. 玩家登录网络面板帐户。
2. 转到余额或钱包页面。
3. 他选择要加载的金额。
4. 选择 PayTR、Paywant 或有效付款方式之一。
5. 您将被引导至付款页面。
6. 完成支付交易。
7. 支付提供商将成功结果通知专家组。
8. 面板将金额添加到玩家的余额中。
9. 玩家可以看到钱包中的当前余额。
10. 玩家可以用这个余额从市场购买物品。

此流程中最关键的一点是正确处理支付提供商的成功返回。如果支付成功后回调或通知不起作用，则可能无法自动添加余额。在这种情况下，应检查付款记录和交易历史记录。

4. 平衡装载区域

在余额充值页面上，向玩家展示了一些基本字段。保持这些字段简单易懂可以减少错误的付款和支持请求。

面积	它是做什么用的？	考虑要点
需充值金额	这是玩家想要添加到其帐户的余额金额。	如果有最小和最大金额，则应清楚地向玩家显示。
付款方式	它决定玩家将使用哪个支付基础设施加载余额。	不应向玩家显示无效的付款方式。
交易概要	付款前向玩家显示金额和交易信息。	玩家在付款前必须看到正确的金额。
当前余额	玩家当前的钱包余额。	付款后应正确更新。

5. 付款后添加余额

付款后添加余额是系统最关键的阶段。即使玩家已经付款，专家组也必须验证该付款是否成功。一旦验证支付成功，相关金额就会添加到玩家的钱包中。

付款后充值过程中的检查事项：

• 支付提供商是否报告交易成功？
• 通知是否与正确的订单或充值记录相符？
• 金额正确吗？
• 货币是否正确？
• 余额是否已添加至正确的会员账户？
• 同一个付款可以处理两次吗？
• 您的交易历史中有记录吗？

6.平衡去杂货店购物

如果玩家账户中有足够的余额，他可以直接用钱包余额购买杂货。在此过程中，无需去找支付提供商；产品价格将从玩家的可用余额中扣除，并创建订单。

以下是平衡杂货购物的运作方式：

1. 玩家进入市场页面。
2. 他选择他想购买的产品。
3. 检查产品价格和描述。
4. 应用优惠券代码（如果有）。
5. 净额与玩家的余额进行比较。
6. 如果余额充足，则购买完成。
7. 净额将从玩家的余额中扣除。
8. 创建订单记录。
9. 产品进入自动或手动输送流程。

如果此流程中余额不足，应向玩家发出明确警告。 “资金不足”警告可能会将玩家重定向至余额充值页面。

7. 使用优惠券时余额如何计算？

如果玩家使用优惠券购买杂货，则从余额中扣除的金额必须是折扣后的净额。因此，必须正确计算产品价格、优惠券折扣和最终付款金额。

Örnek:

Ürün fiyatı: 100 TL
Kupon indirimi: %20
İndirim tutarı: 20 TL
Bakiyeden düşmesi gereken net tutar: 80 TL

如果玩家提示“我使用了优惠券，但超额余额已被扣除”，则应检查订单明细中是否已使用优惠券。订单记录中需分别查看产品价格、优惠码、折扣金额、净额。

8. 余额交易记录

余额交易历史记录显示玩家账户中的所有余额变动。该历史记录是支付和市场支持请求中最重要的记录之一。通过这些记录就可以了解为什么玩家平衡会发生变化。

交易历史应包含以下信息：

• 交易日期。
• 交易类型：充值、消费、退款、手动添加、手动扣除、抵扣。
• 交易金额。
• 交易前的余额。
• 交易后余额。
• 相关订单号。
• 付款方式。
• 解释是否有管理员干预。
• 执行操作的管理员或系统资源。

如果没有交易历史，解决余额问题就变得非常困难。未经注册，无法对“我的余额减少”、“余额未到”等请求给予明确答复。

9.添加手动平衡

手动余额添加是由管理员将余额直接转入玩家的钱包。由于此过程在财务上很敏感，因此仅应在必要时使用。

在以下情况下可能需要手动添加天平：

• 如果支付成功但没有自动添加余额。
• 如果由于技术问题而未处理付款回调通知。
• 如果玩家会得到补偿平衡。
• 如果余额将被定义为活动奖励。
• 如果试算平衡表将添加到测试帐户中。
• 如果管理员将在特殊活动范围内定义余额。

手动添加余额时，必须写出说明。该声明应说明添加余额的原因、与哪项付款或支持请求相关，以及订单或交易编号（如果有）。

Örnek manuel bakiye notu:

PayTR ödeme başarılı göründü fakat callback işlenmedi.
Oyuncu destek talebi #124 üzerinden doğrulandı.
100 TL bakiye manuel eklendi.

10. 手动余额扣减

手动余额扣减是管理员从玩家钱包中扣除余额。这个过程应该更加仔细地完成。因为它影响了玩家当前的权益。

手动余额扣除适用于以下情况：

• 如果错误地添加了多余的余额。
• 如果由于双重付款处理而导致余额被反映两次。
• 如果测试账户中的余额会被清空。
• 如果不正确的补偿余额要被冲销。
• 如果检测到滥用并且政策允许。

在扣除手动余额之前，必须审核玩家的交易历史。玩家可能不小心花掉了市场上额外增加的余额。在这种情况下，订单、产品交付和管理政策应该一起评估。

11. 退货程序

退款是指将玩家之前支付或花费的金额返还给玩家。在余额系统中，退款可以通过两种方式进行：将余额退还至玩家的钱包或通过支付提供商退还实际付款。这两个过程彼此不同。

以下情况可以退还余额：

• 玩家余额减少但产品无法交付。
• 由于库存或技术原因，产品无法交付。
• 服务器政策接受因购买不正确的产品而产生的退货。
• 由于RCON错误，产品无法交付，首选余额退款而不是产品。
• 经理想要补偿性退款。

实际付款退款可能与支付提供商面板有关。此交易不应与网络面板余额混淆。如果玩家同时收到付款退款和余额退款，则可能会发生双倍退款。

12. 薪酬余额

补偿余额是由于玩家遇到的问题而出于善意或解决目的而给予玩家的额外余额。不应针对每个问题自动应用补偿。应根据服务器管理策略以受控方式使用它。

可以给予补偿余额的情况：

• 如果出现交货时间长的问题。
• 如果玩家在付款后遇到技术性延迟。
• 如果由于市场错误而发生受害者。
• 如果因服务器维护而无法使用所购买的服务。
• 如果管理员想要实施自定义支持解决方案。

如果给出补偿余额，则应在交易历史中明确说明这是补偿。否则，以后就不清楚这笔余额是付款、赠与还是退款。

13. 余额与付款方式的关系

余额系统可以与 PayTR、Paywant 或面板上激活的其他支付方式结合使用。每种支付方式可能有自己的交易通知系统。因此，如果付款方式设置不正确，余额充值过程可能会中断。

因付款方式出现余额问题时应检查的事项：

• 付款方式是否有效？
• 商户信息是否正确？
• 回调或通知URL是否正确？
• 支付提供商是否报告交易成功？
• 专家组是否正确处理此通知？
• 交易金额和面板上显示的金额一样吗？
• 玩家是否登录了正确的帐户？
• 同一个付款可以处理两次吗？

解决余额问题时还应检查付款方式设置。仅仅查看玩家的帐户并不总是足够的。

14. 如果玩家说“我已付款但余额未收到”，则需要检查一下

此支持请求是最常见的平衡问题之一。检查应按特定顺序进行，而不是随机进行。

1. 请求玩家的网络面板用户名。
2. 需要玩家的付款电子邮件地址。
3. 要求付款日期和金额。
4. 了解使用哪种付款方式。
5. 在支付提供商面板中搜索交易。
6. 检查交易是否成功、待处理或不成功。
7. 检查面板上是否已创建余额上传记录。
8. 检查余额是否已添加到正确的会员帐户。
9. 检查玩家是否使用错误的帐户登录。
10. 余额添加后，检查是否已在市场上花费。
11. 如果出现回调错误，则通过注释完成手动余额添加。

Oyuncuya örnek cevap:

Merhaba,

Ödeme kaydınızı kontrol edebilmemiz için ödeme yaptığınız e-posta adresini, ödeme tutarını, işlem tarihini ve kullandığınız ödeme yöntemini iletmeniz gerekmektedir.
Bilgileri gönderdikten sonra ödeme sağlayıcısı ve panel bakiye kayıtlarınızı kontrol edeceğiz.

15. 如果玩家说“我的余额丢失了”，请检查订单

如果玩家说他的余额减少了，应该首先检查交易历史。余额可能已用于杂货购物，净额可能在使用优惠券后减少，可能已进行手动更正，或者可能已应用退款/退款流程。

1. 检查玩家当前的余额。
2. 余额交易历史记录打开。
3. 检查最新的余额变动。
4. 检查是否因杂货订单而进行了扣除。
5. 检查订单是否成功。
6. 检查产品是否已交付。
7. 检查优惠券折扣计算是否正确。
8. 如果有手动余额扣除，则阅读其解释。
9. 如果扣除不正确，则做出退款/补偿决定。

对于此类请求，必须给予玩家明确的解释。例如，“已从您的 30 天 VIP 套餐订单余额中扣除 80 TL”等基于记录的答案更让人放心。

16. 如果玩家说“我的余额低，但产品尚未到达”，则需要检查一下。

这涉及平衡系统和杂货配送之间的连接。天平可能已正确下降；但 RCON 交付可能失败。因此，余额、订单和 RCON 日志都应该检查。

1. 有一个平衡运动。
2. 确定扣除哪个订单的余额。
3. 检查订单付款状态。
4. 检查订单交付状态。
5. 检查产品是否自动交付。
6. 检查RCON命令是否运行。
7. 如果有 RCON 错误消息，则会读取原因。
8. 检查 Minecraft 用户名是否正确。
9. 如果产品是手动交付的，则会附有备注。
10. 如果产品无法交付，则余额将被退还，并会输入备注。

17. 余额限制

Minimum and maximum loading limits can be used in the balance system. These limits are determined by payment provider requirements, commission balance, abuse risk and market prices.

可以使用限制的区域：

• 最低余额充值金额。
• 一次性余额充值上限。
• 每日上传限制。
• 每月上传限制。
• 新账户的限额低。
• 手动检查可疑帐户。

必须向玩家明确限制。如果玩家不明白为什么他不能加载低于或高于一定金额的余额，他会提出支持请求。

18. 平衡安全

Since the balance system is linked to payment and the market, it must be carefully protected for security.不应将管理面板中编辑余额的权限授予所有人。未经授权或粗心的管理员可能会向玩家添加不公平的余额或意外减少玩家余额。

平衡安全提示：

• 向有限的管理员授予手动平衡权限。
• 对每个手动操作强制进行披露。
• 交易历史记录不应被删除或修改。
• 在验证付款之前不应添加余额。
• 应检查同一付款是否被处理两次。
• 大额交易应单独审查。
• 应跟踪可疑的多个帐户。
• 应定期检查管理日志。

19. 余额报告和日常控制

应定期检查平衡系统。日常控制可以让您在玩家开放支持之前注意到支付和市场流程中可能出现的任何问题。

每日余额清单：

• 今天进行了多少余额充值？
• 成功付款的次数是多少？
• 有待付款吗？
• 是否有付款成功但余额未添加的记录？
• 即使添加了余额，玩家是否在市场上花钱了？
• 是否存在大量手动余额交易？
• 是否为手动交易编写了解释？
• 退款或补偿交易是否已正确记录？
• 同一个付款可以处理两次吗？
• 是否存在可疑的多个帐户或异常活动？

如果不定期报告，不正确的余额交易将会在晚些时候被发现。这可能会导致收入损失和玩家不满。

20. 常见错误

手动添加余额，无需验证付款

不应仅仅因为玩家说他已付款就添加余额。支付提供商和面板交易记录必须经过验证。

不检查玩家是否登录了错误的帐户

余额可能已添加到正确的帐户；但玩家可能会使用不同的帐户登录。应比较会员帐户和付款电子邮件。

不在手动过程中编写描述

没有说明的手动余额交易，以后无法查询。每次添加、删除、退款或补偿均须注明。

如果出现余额减少但产品未到的问题，只需查看余额屏幕即可

在这种情况下，还必须检查订单和 RCON 交货状态。问题可能是由于交付而不是余额造成的。

在同一笔交易中同时提供产品和退款

如果产品已交付给玩家，则同一笔交易的余额不应退还。退货或交付决定必须通过注册做出。

不检查交易记录就回复

答案应该基于玩家的交易历史，而不是他的主张。未经适当检查记录而给出的答案可能是不正确的。

21. 提出支持请求之前的清单

• 玩家是否使用正确的网络面板帐户登录？
• 付款是通过哪个电子邮件地址进行的？
• 付款日期和金额是多少？
• 付款方式是什么？
• 支付提供商是否显示交易成功？
• 面板中有余额上传记录吗？
• 余额是否已添加到正确的帐户中？
• 余额交易历史中是否有记录？
• 余额是否用于购买杂货？
• 如果使用优惠券，净额是否正确？
• 从余额中扣除哪个订单？
• 订单已交付吗？
• 是否存在 RCON 传送错误？
• 是否进行了手动余额交易？
• 有手动流程说明吗？
• 之前有退款或赔偿过吗？
• 同一个付款可以处理两次吗？
• 管理事务日志中是否有相关记录？

22. 安全和管理建议

• 未经付款验证，请勿添加余额。 对于财务安全来说，这是必要的。
• 未经解释，请勿执行手动操作。 每笔交易都必须登记。
• 限制余额授权。 并非每个管理员都应该有权编辑余额。
• 维护交易历史记录。 这是平衡问题的最重要根源。
• 验证玩家帐户。 登录错误的帐户是一个常见问题。
• 请勿同时退货和交付。 可能会出现双重补偿。
• 还要检查大额交易。 及早发现错误或滥用。
• 每天查看待付款。 无需玩家打开支持即可检测到问题。
• 使用优惠券消费时请核对净额。 减少虚假折扣投诉。

23. 常见问题

玩家说他已经付款，但余额不可见。我应该首先寻找什么？

您必须首先检查玩家登录的帐户、付款的电子邮件地址、付款金额、付款方式以及付款提供商注册情况。如果支付成功，应检查面板上是否有余额记录。

付款截图足以添加余额吗？

不。仅靠屏幕截图是不够的。支付提供商记录、面板交易历史记录和玩家帐户必须一起验证。

玩家的余额减少了，但产品却没有到达。应该做什么？

必须从余额变动中找到相关订单，必须检查订单交付状态和RCON日志。如果产品无法发货，可以人工发货或余额退款；交易必须注明。

手动添加余额安全吗？

通过适当的验证和披露，可以安全地完成此操作。但是，在没有验证付款、没有支持记录或没有写明原因的情况下手动添加余额是不正确的。

退款应该以余额形式退款还是从支付提供商处退款？

这取决于服务器政策和付款状态。余额退款会增加玩家面板钱包中的金额。实际付款退款是通过支付提供商进行的。同一笔交易不得同时使用两种退款方式。

如果玩家将资金转入错误的账户怎么办？

首先，必须安全地验证两个帐户属于同一玩家。然后可以根据服务器策略进行余额转移或手动更正。必须写交易票据。

为什么余额交易历史很重要？

诸如玩家余额何时加载、何时花费、链接到哪个订单以及是否进行手动交易等问题的答案都可以在交易历史中找到。这些记录对于正确解决支持请求至关重要。

结论

Minecraft Web 面板余额系统和钱包交易是基本的金融基础设施，允许玩家通过付款为帐户添加余额，并用此余额购买杂货产品。余额充值、支付后余额添加、买菜、优惠券折扣、手动余额、退款、补偿和交易记录是该系统的主要部分。

管理余额交易时应仔细检查付款验证、正确的会员账户、交易历史、订单链接、RCON 交付状态和手动交易备注。如果玩家提出“我已付款但余额未到”、“我的余额减少”或“我的余额减少但商品未到”等请求，则应根据面板记录做出决定，而不仅仅是玩家消息。

当余额系统得到正确管理时，杂货购物变得更快，玩家钱包体验得到改善，支付支持请求减少，并且 Minecraft Web 面板拥有更可靠的销售基础设施。不正确或未注册的余额交易直接对玩家信心、财务秩序和支持质量产生负面影响。

本文是专门为PvPServer准备的。