Short-form video app coin wallets and episode unlocks

Define exactly what the viewer buys

Start with one proposed offer. Specify the credit pack, its displayed price, the credits supplied and the cost of unlocking an episode. Show the price and currency clearly for the launch market, and make the episode cost visible before the viewer spends credits.

Decide whether an unlock covers one episode or a bundle, and whether an already unlocked episode can ever trigger another debit. If automatic unlocking of the next episode is proposed, agree how viewers enable it, see the cost and stop further spending. A cliffhanger should not make the payment decision unclear.

Ask the supplier to confirm the permitted billing route and product configuration for the Australian storefronts you intend to support. A web checkout and a native app may have different requirements. Avoid adding cross-platform purchasing to the quote as an assumed checkbox.

On Apple’s in-app purchase route, purchased credits must not expire. Keep purchased credits identifiable if promotional credits are also planned, and have the supplier review each offer against the applicable platform rules.

Keep purchases, credits and unlocks connected

Ask to see three linked records in the support view: the verified store purchase, the credit additions and deductions, and the episodes the viewer has unlocked. A single balance number cannot explain why someone was charged or why an episode remains locked.

Each purchase needs a stable reference so a repeated payment update cannot add another pack. For Google Play, the integration needs to recognise an already-processed purchase token before adding credits. Treat a retry as another attempt to finish the same purchase, rather than a new sale.

Apply the same discipline when credits are spent. Ask the supplier to demonstrate a double tap and two devices attempting the same unlock. The agreed outcome should be one deduction and one usable episode entitlement, with no second charge for reopening it.

These are acceptance requirements for the proposed product. The supplier should explain how its chosen architecture meets them, rather than claiming that an app-store connection handles everything automatically.

Make unfinished purchases visible

A viewer may leave the app before a purchase finishes. Agree what they see while it is pending, how the app checks again and who investigates a purchase that remains unresolved.

For Google Play purchases, benefits must wait until the purchase is verified and its state is purchased rather than pending. Ask for both outcomes in testing: a delayed purchase that succeeds and one that does not complete. Credits should appear only for the successful purchase.

Google also requires successful purchases to be acknowledged within its processing window. For consumable packs, consuming the store purchase fulfils that acknowledgement and allows the pack to be bought again. This store-processing step is separate from the viewer spending the credits on episodes. Ask the supplier to show that credits are recorded correctly before store processing finishes.

Test a connection failure after payment as well. The recovery should establish what already happened and finish any missing step without asking the viewer to buy another pack.

Plan recovery beyond a restore button

Apple’s store restore mechanism does not restore consumable purchases. A coin pack is typically configured as a consumable, so a restore button alone is not a complete plan for recovering the service’s credit balance and unlocked episodes.

Ask how those records are associated with the viewer’s service account. If guest purchasing is allowed, define what happens when the person later signs in, changes devices or loses access to the original installation. Have the supplier demonstrate the approved recovery route without creating a second wallet or attaching someone else’s purchases.

Reinstall the app after buying credits and unlocking an episode. Check the unspent balance and the episode separately. Restoring access should not replenish credits already spent, and a zero balance should not make previously unlocked episodes require payment again.

If a shared wallet across iOS, Android or web is proposed, verify the allowed product design and test each supported route. Do not promise portability merely because the same email address works on every screen.

Use a small acceptance script

Run these cases on every purchase channel in scope, using the relevant test facilities:

• Buy a pack and confirm the correct credits appear once.
• Repeat the purchase update and check that the balance stays unchanged.
• Complete a pending purchase while the app is closed, then reopen it.
• Interrupt an episode unlock and retry it without another deduction.
• Attempt the same unlock from two devices using the same service account.
• Reinstall, recover the account and check both the remaining balance and unlocked episodes.

Record the expected result, observed result and any unresolved issue. Include a support demonstration: staff should be able to trace the purchase and unlock history without asking the viewer to repeat the payment. Define who can correct a balance and keep a record of each adjustment.

Put the operating rules in the scope

Request separate estimates for store billing, credit records, episode access, account recovery and support tools. Agree how approved refunds or reversals affect the associated credits and unlocks, without erasing unrelated purchases. Review customer terms separately from the technical tests.