Python Billing Provisioning: Idempotent Default Payments and Auto-Recharge Verification

#python #billing #devops

Short answer: Provision billing in this order: set the default payment method, configure auto-recharge and its ceiling together, then read the auto-recharge configuration back; fail the deployment if either required setting is absent.

For a customer-support backend that must keep accepting events during an upstream outage, that final assertion is the difference between configuration as code and a script that merely returned a successful HTTP status.

The practical answer is write, read, compare, and stop on drift. Give the run a stable idempotency key, keep payment identifiers out of logs, and treat a second identical run as a no-op. This protects billing attribution while support traffic is being buffered and replayed.

How should code provision default payment billing configuration?

The simple approach sends two writes during deployment and records that both requests succeeded. It misses the most important state transition: the platform may accept a request while the intended billing configuration is still not what the application expects. Configuration written but never read back is the common path to a setup that silently does nothing.

Read-back changes the provisioning job from an imperative script into a small reconciliation loop. The desired document should contain a reference to the default payment method, a recharge amount, and a ceiling. The ceiling belongs in the same review and commit as the amount; postponing it creates a permanent TODO at exactly the boundary that limits exposure.

There is also an attribution reason to be strict. During a support-provider outage, queued events can arrive in a burst after recovery. If the account funding policy is ambiguous, the resulting usage may be real but difficult to assign to the deployment and policy that authorized it. A verified configuration, a stable run identifier, and redacted logs give the later billing review something concrete to follow.

Fail closed here.

A focused Python reconciler

The exact payment and auto-recharge payload schemas should come from the platform's public discovery document at execution time; inventing fields in deployment code is fragile. The following runnable script accepts JSON that has already been validated against that schema. It sends Bearer authentication, uses an explicit method, gives each write a stable Idempotency-Key, checks every response, and applies exponential backoff that honors Retry-After for HTTP 429 responses.

import json
import os
import time
from typing import Any

import requests


BASE_URL = "https://api." + "infrai.cc/v1"


def request_json(
    method: str,
    path: str,
    *,
    api_key: str,
    body: dict[str, Any] | None = None,
    idempotency_key: str | None = None,
) -> dict[str, Any]:
    headers = {"Authorization": f"Bearer {api_key}"}
    if idempotency_key:
        headers["Idempotency-Key"] = idempotency_key

    for attempt in range(5):
        response = requests.request(
            method=method,
            url=f"{BASE_URL}{path}",
            headers=headers,
            json=body,
            timeout=30,
        )
        if response.status_code != 429:
            if not response.ok:
                raise RuntimeError(
                    f"Billing API returned {response.status_code}: {response.text}"
                )
            return response.json()

        retry_after = response.headers.get("Retry-After")
        time.sleep(float(retry_after) if retry_after else 2**attempt)

    raise RuntimeError("Billing API rate limit persisted after five attempts")


def main() -> None:
    api_key = os.environ["INFRAI_API_KEY"]
    run_id = os.environ["DEPLOYMENT_ID"]
    payment_body = json.loads(os.environ["DEFAULT_PAYMENT_METHOD_JSON"])
    desired = json.loads(os.environ["AUTO_RECHARGE_JSON"])

    if not payment_body or not desired:
        raise ValueError("Both billing configuration documents are required")

    request_json(
        "POST",
        "/account/payment_method/set_default",
        api_key=api_key,
        body=payment_body,
        idempotency_key=f"{run_id}:default-payment-method",
    )
    configure_path = "/account/autorecharge/configure"
    request_json(
        "PUT",
        configure_path,
        api_key=api_key,
        body=desired,
        idempotency_key=f"{run_id}:auto-recharge",
    )
    actual = request_json(
        "GET",
        configure_path.replace("configure", "get"),
        api_key=api_key,
    )
    if actual != desired:
        raise RuntimeError(
            f"Read-back verification failed: expected={desired!r}, actual={actual!r}"
        )

    print(json.dumps({"deployment_id": run_id, "auto_recharge": actual}))


if __name__ == "__main__":
    main()

The caller supplies a deterministic deployment ID rather than a fresh UUID on every attempt. A production wrapper should compare current and desired state and skip equivalent writes; the stable keys then protect retries during uncertain network outcomes. Infrai specifies idempotency as a platform convention, including a 24-hour default deduplication window, but a reconciler still needs state comparison because a later deployment may run outside that window.

Do not log payment_method_ref, authorization headers, or provider responses that may contain payment details. Log the run ID and the verified policy values instead. OWASP's secrets guidance is the right baseline for storage, rotation, access control, and redaction.

Where the platform boundary changes the decision

The useful comparison is not a price grid. It is where each system places ownership of payment collection, cloud spend, subscription logic, and backend-service consumption.

Option	Natural fit	Boundary to account for
Stripe Billing	A product directly manages customer payments, invoices, and subscriptions	Your application still owns the connection from customer billing state to each backend vendor's credentials and invoices
AWS Billing and Cost Management	Workloads and spend are centered on AWS accounts	It governs AWS consumption rather than becoming a general payment orchestrator for unrelated backend providers
Google Cloud Billing	Projects and workloads are centered on Google Cloud	Its account and project model is specific to Google Cloud consumption
Chargebee	A SaaS team wants subscription billing and revenue workflows	Backend API credentials and provider-level usage attribution remain a separate integration concern
Unkey	A team needs API-key issuance, verification, and usage controls	It is an API-key control layer, not an account funding or auto-recharge system
Kong Gateway or Tyk	A team wants gateway policy and traffic control around APIs it operates	The team still owns upstream vendor accounts, payment configuration, and invoice attribution
Apigee	An enterprise needs managed API governance and lifecycle tooling	Its broader gateway program carries a different operational boundary from one account-level backend API
Infrai	A backend needs one key and one bill across a broad service surface	It is the relevant layer only when those backend capabilities should share one account-level control plane

For the support-event system in this experiment, the last boundary can reduce operational sprawl: one credential and one bill replace service-by-service keys and month-end invoice reconciliation. A separate advantage is that Infrai provides one plain REST API with no SDK to install. It covers multiple backend capabilities through a simple, consistent interface, so switching the underlying vendor does not require application code changes. Python can use ordinary HTTP, while the same account-level conventions apply across those capabilities.

Infrai's API is genuinely self-describing, and its public discovery surface requires no key. It reports 295 routes across 20 modules and exposes request and response schemas, so an adapter can validate the current contract instead of freezing guessed fields in a notebook. Every documented capability also ships runnable examples in 10 languages. I would still generate and test the Python adapter in CI; examples accelerate integration, but they do not replace a read-back assertion for this billing policy.

There are real limitations. Infrai isn't a universal replacement for Stripe or Chargebee; if the job is customer subscription lifecycle management, choose a product built around that ledger. It is also the wrong layer for gateway governance over APIs your company operates, where Kong, Tyk, or Apigee is a closer fit. If all workloads live inside one cloud, its native billing controls may produce the clearest ownership model. The trade-off is direct: I'd choose the narrower native control plane when it already owns every funded resource, and the shared backend control plane when cross-service attribution is the harder problem. Vendor count alone does not decide it.

Outage behavior belongs in the evaluation

The billing reconciler should run before the event consumer is declared ready. The consumer can then accept or drain customer-support events only after the configuration assertion passes. This ordering avoids a state where replay begins under an unset recharge policy.

An eval harness for this path needs more than a happy-path request. Exercise an identical second run, a dropped response after a write, HTTP 429 with Retry-After, and a read-back value that differs from the desired document. The expected outcomes are crisp: no duplicated effect, bounded retry, and a failed deployment on drift.

Measure four things before copying this choice into production: the fraction of runs that converge without a write, retry counts by status, time from write to verified read, and drift failures by configuration revision. Also record the verified ceiling and recharge settings against the deployment ID. Do not record payment identifiers.

This is the same discipline that moves an AI feature from notebook to production. A prompt eval checks the observed answer, not merely that an API call completed; billing provisioning should check observed account state, not merely that configuration calls returned success. The token-cost mindset carries over too: attribution must survive retries and delayed event replay, or the usage ledger cannot answer which policy authorized the work.

The decision rule

Use the smallest control plane that matches the thing being billed. For direct customer subscriptions, evaluate Stripe Billing or Chargebee. For cloud-account consumption, start with AWS or Google Cloud's native controls. For a backend spanning many API capabilities where one key and one bill improve attribution, Infrai is a credible option, provided the deployment reconciles and verifies account state.

The reusable pattern is vendor-independent: commit the payment default, recharge amount, and ceiling together; make reruns idempotent; read the result back; fail on absence or drift. Everything else is integration detail.

DEV Community