ZShip uses credits as the product-level spending unit and plans as the commercial packaging around those credits.
What users can do
- Compare plans on
/pricing - Review current balance on
/dashboard/credits - Inspect active subscription status on
/dashboard/subscription - Review previous purchases on
/dashboard/orders
How the flow works
- The visitor chooses a plan on the pricing page.
- Checkout is created through the pay-service proxy.
- Successful payment updates subscription state and the credit ledger.
- Dashboard pages read the latest balance and order records from the same backend state.
What to validate before launch
- Pricing labels and descriptions match the plans configured in the pay service.
- Credit amounts are easy to understand from a user perspective.
- Refund expectations are documented and linked from support.
- The support team knows which cases should go through tickets versus payment provider portals.
Common launch questions
When should I send users to pricing?
Send users to pricing when they run out of credits, need a higher plan, or want to understand what each tier unlocks.
Where should refund requests go?
Use the support flow documented in Support and refund. The dashboard order history already exposes refund requests as a product-level action.