1. Credit categories
The service may allocate free, subscription and pay-as-you-go credits. Product-scan and deep-scan balances remain separate where the backend treats them separately.
Quantities, reset periods, expiry, export limits and saved-opportunity limits must come from validated plan data or approved configuration.
2. Store-managed pricing and purchasing
Eligible Apple App Store and Google Play products use store-managed pricing. The website does not invent or independently confirm a price when the live catalogue is unavailable.
A client callback alone never creates entitlement; the backend must validate the store transaction and bind it to the authenticated account.
3. Validation states
Transactions may be pending, valid, invalid, duplicated, refunded, partially refunded, revoked or otherwise unresolved according to backend and store records.
Invalid, duplicated or pending records do not create entitlement unless the validated backend workflow grants one.
4. Credit grants and reversals
Credits are granted only after eligible free allocation, subscription allocation, validated pay-as-you-go purchase or authorised administrative adjustment.
Credits may be reversed when a purchase is refunded, revoked, duplicated, invalidated or otherwise loses entitlement under validated records and rules.
5. Reservation, consumption and expiry
An eligible credit may be reserved when a scan begins and consumed when the backend reaches the applicable processing state.
Credits expire only where the relevant plan, purchase or allocation rules provide expiry; expired credits are not available.
6. Scan failure and cancellation
A failed or cancelled scan does not automatically create a cash refund. The backend decides whether a reserved credit is consumed, released or restored from the actual scan state and rules.
Users should review the credit ledger or contact configured support when scan and credit states appear inconsistent.
7. Renewal and cancellation
Subscription billing, renewal timing, pricing and cancellation are managed through the applicable Apple App Store or Google Play account and store rules.
Cancellation generally prevents a future renewal; it does not necessarily reverse a validated period or create a refund.
8. Restoration
Supported restoration lets the backend re-check eligible Apple or Google purchase history and subscription status for the authenticated account.
Restoration cannot create entitlement for another account’s transaction or one that is invalid, refunded or revoked.
9. Refund requests
Refund eligibility depends on the store process, transaction state, service already supplied, applicable store rules and mandatory consumer rights.
Users may need to request refunds through Apple or Google. AL ANSB does not promise a refund unsupported by the backend or store.
10. Duplicate, pending, refunded and revoked records
Duplicate transactions should be reconciled by provider identifiers before credits are granted. Pending transactions remain unresolved until provider and backend confirm a final state.
Refunded or revoked records may cause corresponding credit reversals to the extent supported by backend records and applicable rules.
11. Contact and policy status
Questions should use configured support and include enough non-sensitive information to identify the account and transaction. Users must not send passwords, private keys or full purchase tokens.
This policy should be read together with the applicable Apple App Store or Google Play terms and any mandatory consumer rights. Where a mandatory law or store rule controls a transaction, that rule applies to the extent required.
