Evaluate a WooCommerce wallet plugin by following credit creation, spending, refunds and the resulting balance records. Define what the store’s credit means and which authorised action changes it. A useful acceptance exercise reconciles the order and wallet history, including a partial-credit purchase, instead of treating a visible account balance as sufficient evidence.
Start with the store’s approved policy and customer journey. Identify how credit can arise, who can authorise an adjustment and what a customer should understand when using it. Keep the proposed software behaviour and any commercial or legal terms as separately reviewed decisions before configuring the extension.
What does the selected extension actually document?
Account Funds documentation provides one product-specific example. Account Funds supports using store credit for part of an order alongside another payment method. Include that mixed-payment journey in the requirements if it is part of the proposed store, and identify the other payment method whose behaviour must be verified.
Account Funds documents refunds into a customer’s account funds. Distinguish that route from returning money through a payment provider. Ask the operator to identify which outcome is intended before processing a sample refund, and ensure the customer-facing explanation describes the approved policy accurately.
Reward configurations can set an expiration time for awarded credit. Account Funds supports configurable awarded-credit and expiring-credit emails. If expiry is part of the proposed arrangement, record its policy owner, applicable credit source and communication requirements. Use the actual approved terms rather than inventing a validity period for the demonstration.
Account Funds can award cashback from paid-order or product-purchase triggers. Have the implementer show which configured rule applies to the sample transaction. Record its eligibility and state so a later reviewer can explain why credit was or was not awarded without guessing from the resulting balance.
Which records should explain a balance change?
Account Funds transactions can be browsed through the Wallets screen. Individual wallet transactions can be inspected. Ask the operator to follow the sample order into the relevant transaction history and identify the entry that explains the change. Retain the reference and the observed relationship in the acceptance record.
Give each proposed credit source a clear description in the requirements: an approved award, customer-funded credit or a refund route may need different operating decisions. Confirm the chosen extension’s support for the intended source before describing it as available. Keep manual adjustments identifiable in the review process.
Compare the balance change with the intended event. A credit entry and a successful purchase are related records, but they answer different questions. The person reviewing the ledger should be able to explain which action created an entry and which order or approved decision supports it.
| Scenario | Question for the operator | Evidence to retain |
|---|---|---|
| Credit is awarded | Which configured rule applied? | Rule context and resulting wallet entry |
| Part-credit purchase | What portion used credit and what used the other method? | Order payment breakdown and wallet change |
| Refund to credit | Was account credit the approved destination? | Refund decision and corresponding credit entry |
| Refund through a gateway | Did the documented gateway route complete? | Order notes and relevant provider evidence |
| Manual balance correction | Who authorised the reason and change? | Adjustment reference and reviewed explanation |
This original reconciliation worksheet asks for evidence at the boundary between the order and credit record. Adapt the operating roles to the actual store, leaving unsupported behaviour as a requirement to investigate rather than an assumed plugin feature.
How do standard WooCommerce refunds affect the review?
WooCommerce’s refund guidance distinguishes the standard routes. WooCommerce automatic refunds require a compatible payment gateway. Check the selected provider’s current documentation and the installed integration before treating an automatic refund route as demonstrated.
WooCommerce manual refunds record the refund while money must be returned separately. Changing an order status directly does not automatically refund the customer. The operator’s handover needs to make these distinctions understandable so the visible order state is interpreted alongside the actual intended return route.
For a purchase using credit and another method, ask how the proposed configuration assigns the refund. Retain product-specific documentation and the observed sample result for that arrangement. Avoid extending the general refund guide into a claim about the wallet’s mixed-payment allocation unless the selected product evidence supports it.
Review the customer-facing message alongside the records. It should explain the outcome the approved process actually produced and the next step, where relevant. Keep promises about redemption, transfer or settlement with the business’s confirmed policy and applicable verification rather than deriving them from a label such as “wallet.”
Original mixed-payment and refund exercise
Use a fictional customer purchasing a notebook and a folder in a separate test store. Prepare an approved sample credit source and the other payment method’s documented test arrangement. The exercise follows a part-credit order and a later refund, using symbolic ledger entries rather than public prices.
First, record the customer’s starting sample balance and the event intended to add credit. Trigger the approved sample rule and inspect its entry. Compare the source, customer identity and resulting balance with the expectation written before the exercise. Record an unexplained entry as an issue to investigate.
Next, place the sample order through the part-credit route. Inspect the order breakdown and wallet transaction together. Ask the operator to explain how the credit change relates to the order and which evidence supports the other payment component. Keep each layer’s test result distinguishable in the record.
Then apply the approved sample refund route to the notebook while leaving the folder in the order. Inspect the destination, order information and wallet history using the documented configuration. If the result differs from the intended policy, retain that difference and ask the product and policy owners to resolve it before acceptance.
Finally, review a proposed manual correction with the person responsible for credit adjustments. Identify the supporting reason, authorisation and reference the operating process needs. Retain the configuration and sample ledger with the exercise so later reviewers can follow the balance changes and the outstanding questions.
What should the handover make easy to review?
Document who maintains reward rules, reviews discrepancies and answers a customer enquiry about a balance. Give support staff a safe reference route and a clear escalation owner. Keep sensitive account information and credentials in the appropriate private operational records.
Repeat the relevant exercise when the selected extension, payment integration or policy changes. The useful outcome is a traceable explanation of each tested balance movement, with unresolved behaviour and its owner visible in the record.
For related work, see online payments and WordPress. Get started with the proposed credit policy and the order-to-wallet questions you need to verify.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.