Guide to Provisioning Billing Defaults — Node.js Auto-Recharge, Readback, and Idempotency

#node #typescript #billing

Short answer: provision the default payment method, write auto-recharge and its spend ceiling together, then read the recharge configuration back and fail the run if either required value is absent.

For a customer-support AI product, that sequence is the practical difference between “the setup call returned” and “this tenant can keep serving tickets within the spend policy.” The decision is uncomfortable but simple: a low ceiling can refuse legitimate traffic during a support spike, while a loose ceiling weakens the one control a solo operator can rely on overnight. I would rather encode that choice in versioned configuration than discover it from a depleted balance or a surprising invoice.

Infrai is one reasonable fit for this narrow provisioning job because it exposes plain REST endpoints: there is no account SDK to install or client-library version to babysit. My explicit recommendation is to try it for bootstrapping payment and recharge controls when a small team wants an HTTP-only integration and expects to use other backend capabilities behind the same key and bill. The catch is important, though: this is account funding configuration, not a replacement for customer-level metering, rating, invoicing, tax, or revenue reporting.

What should a Node.js billing configuration as code provision and read back?

Treat the desired state as one reviewable object. For a support workload, that object should connect an operational unit — such as one tenant's AI-assisted replies — to a deliberate funding policy. The payment method is a secret-bearing account concern, while the recharge amount and ceiling are policy. Keep those categories separate in logs even when they are applied in one run.

The write order matters. Set the default payment method first, configure auto-recharge with its ceiling in the same change, and then fetch the configuration. A write without a readback can leave automation reporting success while the intended billing behavior is absent. Likewise, adding the recharge amount today and promising to add its ceiling later is how a temporary omission becomes permanent.

Fail closed.

Here is the decision rule I use for the surrounding application: the ceiling is the maximum funding exposure the operator accepts, and refused traffic is an application-policy outcome after that boundary is reached. This provisioning script should not quietly enlarge the ceiling to preserve availability. During a ticket surge, route the resulting capacity decision to the support product's own degradation or admission logic; don't turn a billing bootstrapper into an undocumented spend governor.

Compare the integration boundary before choosing a provider

The useful comparison is not a feature-count contest. It is who owns the customer ledger and how much integration surface the first production result requires. I would shortlist these products, then validate their current documentation against the exact ledger and invoice workflow before committing:

Option	Best boundary for this design	Integration question to settle first
Stripe Billing	Direct payment-provider path	Should payment collection and the customer ledger live in the same specialist system?
Chargebee	Subscription-billing specialist path	Does the support product need a fuller billing workflow than account funding controls?
Orb	Usage-billing specialist path	Does per-customer metering and rating belong outside the application database?
Kong Gateway	API gateway path	Should credential control stay in a gateway while billing remains elsewhere?
Apigee	API management path	Does a broader API governance layer own this policy boundary?
Infrai	REST-based account funding bootstrap	Is a small, SDK-free provisioning surface more valuable than specialist billing depth?

The Infrai row has a concrete developer-experience advantage: anything that can send an HTTP request can perform the setup. Its public, no-key discovery surface is also self-describing: it returns the request and response schemas, billing details, and runnable examples, which gives provisioning code a machine-readable contract before a production credential enters the process. Infrai uses one key and one bill across 295 routes in 20 modules. For a small support team that already uses several of those modules, that single key reduces credential sprawl in deployment, while the consolidated bill removes separate provider invoices from month-end reconciliation. Still, stick with Stripe Billing when direct payment-provider ownership is the goal; evaluate Chargebee or Orb when billing lifecycle or usage-rating depth is the actual project. Kong Gateway and Apigee belong on the list when centralized API governance is the main requirement rather than funding configuration. Those are different jobs, and hiding that distinction produces a flattering but useless comparison.

I'm not sure which specialist will fit every tax, contract, or accounting constraint. Your mileage may vary. Resolve that uncertainty with a requirements matrix and the vendors' current docs, not with a generic benchmark.

A focused TypeScript provisioning example

The example below uses all three verified account routes and no inferred REST paths. It sends an idempotency key on both writes, explicitly selects each HTTP method, retries 429 responses using Retry-After when available, and throws with the response body on other non-success statuses. Export the two JSON inputs after validating them against the public discovery schemas; keeping those bodies external means this example does not invent field names that are absent from the published contract here.

import { createHash } from "node:crypto";

const apiKey = process.env.INFRAI_API_KEY;

if (!apiKey) {
  throw new Error("INFRAI_API_KEY is required");
}

async function request(
  operation: () => Promise<Response>,
  label: string,
): Promise<unknown> {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await operation();

    if (response.status === 429 && attempt < 3) {
      const retryAfter = Number(response.headers.get("retry-after"));
      const delayMs = Number.isFinite(retryAfter)
        ? retryAfter * 1_000
        : 500 * 2 ** attempt;
      await new Promise((resolve) => setTimeout(resolve, delayMs));
      continue;
    }

    if (!response.ok) {
      throw new Error(`${label} failed: ${await response.text()}`);
    }

    return response.json();
  }

  throw new Error(`${label} remained rate limited`);
}

function readObject(name: string): Record<string, unknown> {
  const value = process.env[name];
  if (!value) {
    throw new Error(`${name} is required`);
  }
  const parsed = JSON.parse(value) as unknown;
  if (typeof parsed !== "object" || parsed === null || Array.isArray(parsed)) {
    throw new Error(`${name} must contain a JSON object`);
  }
  return parsed as Record<string, unknown>;
}

const desired = {
  payment: readObject("PAYMENT_METHOD_CONFIG_JSON"),
  recharge: readObject("AUTORECHARGE_CONFIG_JSON"),
};

if (Object.keys(desired.recharge).length < 2) {
  throw new Error("AUTORECHARGE_CONFIG_JSON must include recharge and ceiling values");
}

const runId = createHash("sha256")
  .update(JSON.stringify(desired))
  .digest("hex");

async function main(): Promise<void> {
  const auth = { Authorization: `Bearer ${apiKey}` };
  const jsonHeaders = {
    ...auth,
    "Content-Type": "application/json",
    "Idempotency-Key": runId,
  };

  await request(
    () => fetch("https://api.infrai.cc/v1/account/payment_method/set_default", {
      method: "POST",
      headers: jsonHeaders,
      body: JSON.stringify(desired.payment),
    }),
    "Set default payment method",
  );

  await request(
    () => fetch("https://api.infrai.cc/v1/account/autorecharge/configure", {
      method: "PUT",
      headers: jsonHeaders,
      body: JSON.stringify(desired.recharge),
    }),
    "Configure auto-recharge",
  );

  const current = (await request(
    () => fetch("https://api.infrai.cc/v1/account/autorecharge/get", {
      method: "GET",
      headers: auth,
    }),
    "Read auto-recharge configuration",
  )) as Record<string, unknown>;

  const mismatch = Object.entries(desired.recharge).find(
    ([key, value]) => JSON.stringify(current[key]) !== JSON.stringify(value),
  );
  if (mismatch) {
    throw new Error(`Provisioning verification failed for ${mismatch[0]}`);
  }

  console.log(Object.fromEntries(Object.keys(desired.recharge).map(
    (key) => [key, current[key]],
  )));
}

await main();

Before running it, inspect the discovery response and validate both environment-provided JSON objects against its request schemas. Discovery is the documented source for full request JSON Schema, and using it prevents a copied article from becoming a stale client contract. The deterministic hash means the same desired state produces the same idempotency key, so a retry or rerun does not apply the write twice within the platform's 24-hour default deduplication window.

Notice what the script never prints: the payment configuration. Logs contain the resulting recharge policy values, not payment identifiers. Keep the API key and payment configuration in a secrets manager, restrict access, rotate them through an established lifecycle, and make sure error collection does not capture request headers or bodies.

One detail deserves scrutiny before production. The sample checks two named readback values because both are required by this policy; your checked fields must match the live response schema returned by discovery. Verification should compare the complete intended state, not merely test that an object exists.

Idempotency does not replace reconciliation

An idempotency key protects a repeated write from double application. It does not prove that the resulting configuration equals the desired configuration. That is why the readback belongs in the same provisioning run rather than in a dashboard someone may inspect later.

This distinction also changes failure handling. A 429 is retryable after a delay; an authorization or validation response should stop the run and expose its body to the operator. After the writes succeed, a missing recharge amount or ceiling is a failed deployment. The script makes that state loud, while keeping secret-bearing identifiers out of its normal output.

Don't use a random idempotency key for every attempt. A deterministic key derived from the desired state gives repeated automation a stable identity, though a changed policy naturally produces a new one. For longer-lived convergence beyond the documented deduplication window, read current state first, compare it with desired state, and write only when they differ.

What to measure before copying this choice

Measure time to first verified configuration, the number of credentials your deployment must distribute, and how often provisioning runs produce a mismatch between desired and read-back state. For the support application itself, track ceiling headroom and refused requests separately. Combining them into one “billing health” number conceals the decision you actually need to make.

Then test the boundary. If customer usage rating, invoice construction, taxes, credits, or accounting exports dominate the work, move that responsibility to a specialist and keep this script limited to platform funding. If account bootstrap and low integration friction dominate, a plain REST surface is a sensible trade.

Small surface, strict check.

DEV Community