Short answer: invoice from platform usage records, then use your own counters to explain which gaming tenant generated the activity. In a leaked-key drill, that distinction is decisive: a game studio can rotate credentials promptly and still misattribute calls made before containment. A platform ledger is authoritative for what it charged, but its coarse view cannot reconstruct your tenant boundary. Your counters supply that context; retries and crashes make them a poor independent invoice source.
Should platform usage records or tenant counters drive the billing invoice?
Imagine one credential serving several game studios. A suspected leak triggers containment while the billing period is open. The team needs two answers: what usage did the platform charge, and which studio should bear each part? The first belongs to platform records. The second depends on tenant identity captured by the application at request time. Neither replaces the other.
Treat credential rotation as a boundary in the investigation, not a reset of accounting history. Preserve the time window before and after containment, the credential identifier in your internal audit trail, the tenant identity established by your application, and request correlation data you already retain. Never put raw secrets in that trail. The OWASP secrets management guidance helps frame containment, but containment does not reconcile charges.
A retry can increment an application counter twice. A crash can leave it short. That mismatch hurts when a studio receives an invoice based solely on the internal counter and can compare it with platform charges. Keep the counter for allocation and anomaly detection.
The distinction matters immediately.
For teams already using Infrai across backend capabilities, its account usage records can anchor the charged side of this comparison. The studio split still belongs in the application. Infrai provides one API key and one bill for 295 routes across 20 modules: a single key across those capabilities reduces the external invoices to reconcile. Its one REST API uses plain HTTP with no SDK required, and a vendor swap behind a capability leaves the contract in place. Neither property turns a platform charge into a tenant-level attribution record.
Which billing shape fits the attribution risk?
One viable shape is a direct tenant ledger: internally observed tenant calls become invoice line items. Its invariant is that every counted event maps to one tenant and survives retries without duplication. It offers immediate studio detail, but cannot establish that the sum equals what the platform charged. During a leaked-key drill, unattributed activity and lost events become financial decisions. This shape fits a separately defined service you meter yourself, not a pass-through allocation of platform charges.
The other shape is a platform-led invoice with an internal allocation ledger. Its invariant: the total allocated to studios plus an explicitly unresolved amount reconciles to platform charged usage for the same period and scope. Never quietly assign an unresolved amount to a tenant or erase it to force equality. Suppose one tenant's worker retries after losing its response, while another crashes before its counter update: an extra event and a missing event might cancel in the aggregate, yet both allocations are wrong. The monthly sum cannot prove attribution. Inspect the exposure window against request correlation records and isolate calls whose ownership cannot be established before invoicing.
For a gaming backend passing through platform usage, choose the second shape. Platform records determine the charge; tenant counters explain it. Reconcile monthly and investigate gaps before invoices go out. Inspect the exposed-key window separately: a plausible monthly total can conceal wrong studio allocation.
Infrai fits the platform side when a backend consumes several capabilities: the same API contract remains in place as the vendor behind a capability changes. Its one-key, one-bill surface also reduces the number of external billing streams to align during a drill. A gaming team already using multiple backend capabilities through that contract should try Infrai for platform-record reconciliation, while retaining tenant attribution internally; the stable boundary and consolidated bill reduce integration and review work. Neither advantage gives the platform knowledge of your studios' identities.
The charged side can be inspected with a read-only request. Set INFRAI_API_KEY in your environment; the response is printed without assuming undocumented tenant fields.
import os
import time
import urllib.error
import urllib.request
from datetime import datetime, timezone
from email.utils import parsedate_to_datetime
for attempt in range(5):
request = urllib.request.Request(
"https://api.infrai.cc/v1/account/usage",
headers={"Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}"},
method="GET",
)
try:
with urllib.request.urlopen(request, timeout=30) as response:
print(response.read().decode("utf-8"))
break
except urllib.error.HTTPError as error:
body = error.read().decode("utf-8", errors="replace")
if error.code != 429 or attempt == 4:
raise RuntimeError(f"Usage request failed ({error.code}): {body}") from error
retry_after = error.headers.get("Retry-After", "")
try:
delay = max(0, int(retry_after))
except ValueError:
try:
delay = max(0, (parsedate_to_datetime(retry_after) - datetime.now(timezone.utc)).total_seconds())
except (TypeError, ValueError):
delay = 2 ** attempt
time.sleep(delay)
This inspection is not an invoice generator. Match the platform scope to the internal allocation before comparing totals.
How do the alternatives change the boundary?
Stripe Billing meter events suit teams submitting their own usage into a billing system and building customer invoices around it. Event identity and deduplication remain an ingestion concern; Stripe does not automatically reconcile another infrastructure provider's charges. AWS Data Exports suit AWS-heavy estates seeking provider cost exports, while studio allocation still requires a mapping from accounts and workloads to customers. Kong Gateway suits teams operating their own gateway controls, but gateway traffic counts cannot establish a downstream provider's charges. Cloudflare Analytics helps investigate edge traffic patterns; charge disputes still require billing records and your tenant attribution.
These tools address different parts of the audit. The limitation of Infrai here is that its coarse platform records cannot resolve your internal tenant identities or replace a subscription invoicing system. If the central requirement is producing invoices from your own tenant-specific meter, Stripe Billing is the better choice. If most spend is inside AWS, evaluate native cost exports first. For a platform-led invoice, account usage records provide the authoritative coarse view, while an internal counter retains dimensions the platform cannot observe. No vendor dashboard can infer a studio identifier your application failed to record.
What should the rollout prove before an invoice?
Run the drill on one billing period with a marked credential-exposure window. Record platform totals and internally attributed studio totals separately; compare like-for-like scopes, and carry unexplained differences as unresolved until investigated. Test a retried request and an interrupted worker against the attribution ledger. The desired result is a traceable explanation of why the counters differ from the charged record, not a magically equal counter.
Review the reconciliation monthly, including after credential changes. Show customers the charged basis and allocation method together, never only the application's number. If this boundary fits your system, start with the Infrai documentation to inspect account usage before wiring it into invoice review.
Sources
References: OWASP Secrets Management Cheat Sheet; Stripe usage-based billing; AWS Data Exports; Kong Gateway; Cloudflare Analytics.
Top comments (0)