# Billing Self-check

Use after Billing code is written or when assessing test and go-live readiness. For product or scenario selection, return to [Product Decision](https://cdn.marmot-cloud.com/page/antom-integration-doc/references/product-decision.md) and the [Billing Router](https://cdn.marmot-cloud.com/page/antom-integration-doc/references/billing.md).

## Route And Scope

- The implementation uses Billing because it needs Billing resources or lifecycle behavior, not only a single charge or recurring auto-debit.
- The selected scenario, capability, and payment path match the merchant request. A resource-only task does not introduce a payment path.
- Only the operations required by that route are implemented; adjacent Billing capabilities are not assumed.

## Resource Handoffs

- IDs returned by Product, Price, Customer, Meter, Subscription, Invoice, and Credit Grant operations are persisted and passed only to documented downstream fields.
- Setup-time resources are not recreated for every request unless the workflow requires it.
- Meter event names and Customer identifiers remain consistent from Meter setup through usage upload and Invoice calculation.
- Invoice collection is not limited to one-time Billing. For Subscription, usage, and overage flows, the implementation follows the Invoice behavior documented by the selected scenario.
- A prepaid package grants credit only after its payment is confirmed; credit creation is not treated as payment confirmation.

## API Contract

- Endpoint, HTTP method, required fields, types, enums, and response fields match the linked Billing API operation document.
- Arrays, nested structures, and map-like fields are represented as such rather than flattened into strings.
- Request identifiers are generated and reused according to the operation contract; retry behavior is not invented when the source does not define it.
- Notification payloads are handled as inbound messages and are not called as ordinary SDK methods.
- SDK package, class, method, and model names match the released version in [SDK Description](https://cdn.marmot-cloud.com/page/antom-integration-doc/references/select-sdk.md) and the selected language's Billing sample. For an operation without an exact sample, inspect that SDK rather than inventing symbols.

## State And Recovery

- An accepted API response, redirect, or accepted Meter upload is not treated as final financial evidence.
- Subscription, Invoice, payment, capture, usage, and credit states are stored separately when the workflow uses more than one of them.
- Final state is confirmed through the notification or inquiry operation documented for the selected flow.
- Duplicate notifications and retried requests do not apply the same business transition twice.
- When the API Reference provides only inquiry and no notification, recovery uses inquiry rather than inventing a notification path.

## Security And Operations

- Private keys and signing remain server-side; secrets, card data, tokens, and personal data are masked in logs.
- Notification signatures are verified before state changes are accepted.
- Development logs include the endpoint and masked request/response evidence needed for troubleshooting.
- Credentials, sandbox checks, and the general [Self-Check List](https://cdn.marmot-cloud.com/page/antom-integration-doc/integration-guides/self-check.md) are completed before go-live guidance is given.