How Avrix treats partner-declared checkout evidence (integrationOrderContext) and related commercial records.
Controller / processor split#
| Party | Role |
|---|---|
| Seller (you) | Independent controller of end-customer personal data — accounts, payments, age gates, marketing. You collect buyer IP and checkout evidence before calling Avrix. |
| Avrix | Processor of partner-declared checkout evidence needed to fulfil digital goods, enforce territory / price rules, and settle with vendors. |
Avrix does not replace your privacy policy, age-gate, or tax engine.
What you send#
integrationOrderContext on commercial mutations may include:
- Territory:
salesCountryCode, optional locale - Network evidence:
consumerIp(required for production commercial evidence) — resolved at request time, not stored: the row keeps the resolved country (detectedCountryCode) and a peppered, truncated hash (consumerIpHash) instead of the address - Retail money: currency + declared gross / net / tax minors
- Optional tax id fields
- Non-PCI payment correlation: payment method family,
paymentProcessorReference,checkoutSessionId
Serialized size is capped. Unknown keys are rejected.
What returns to you#
- Webhooks may include a redacted IOC subset for correlation.
- Excluded from webhook redaction paths: consumer IP, VAT numbers, raw PSP tokens, and similar high-sensitivity fields.
- Game-key plaintext is never a webhook or GET /orders artifact.
Retention#
IOC evidence is retained with the commercial sale / fulfilment ledger for dispute, chargeback, and settlement windows (aligned with finance report periods — typically months, not indefinite product analytics).
The buyer IP is the exception: it is used once, at request time, for the territory
cross-check, VPN / hosting detection and sanctions screening, and then discarded. What persists
is the verdict (detectedCountryCode, countryMismatch) and consumerIpHash, a peppered
truncated sha256 that cannot be reversed to the address. The address observed on the optional
checkout-page confirmation pixel (POST /geo/attest) is cleared automatically once the attest has
expired for 7 days.
Exact schedules are environment- and contract-specific and are defined in your DPA / commercial agreement. Public docs do not publish a single global TTL for ledger rows, webhook delivery history, or audit traces.
Integrator guidance (without inventing platform TTLs):
- Persist every Avrix
requestId/X-Request-Idand webhookeventIdin your logs for at least as long as you need for dispute and support correlation. - Use GET /webhooks/{id}/deliveries and delivery replay while investigating missed events; treat delivery history as operational, not as your system of record for buyer entitlements.
- For DSAR / erasure timelines that touch Avrix-held IOC, follow the table below and your DPA — not a self-serve Seller API delete.
Data subject requests#
There is no self-serve Seller API erasure endpoint for IOC today — ledger integrity and vendor settlement require preserved commercial evidence.
| Request | Your action | Avrix action |
|---|---|---|
| Access / export | Export from your store systems; include orderReference for correlation | On written admin request under your DPA, redacted evidence export for named ids |
| Rectification | Correct data in your store; historical IOC is not silently rewritten | Finance adjustments via refunds / support |
| Erasure | Erase or anonymize your copy of buyer PII; stop sending unnecessary PII | High-sensitivity IOC fields may be anonymized after the contractual retention floor via DPA process — not via public API |
Partner checklist#
- Document Avrix as a processor / sub-processor where required.
- Capture only fields needed for territory, tax evidence, and PSP reconciliation.
- Never log Seller API mutation responses (may contain game keys) or raw webhook secrets.
- On post-charge stock failure, refund at your PSP; then call Avrix refunds if keys were delivered.
- For DSAR affecting Avrix-held IOC, use your DPA / support process with company id and order identifiers.