@vaam-apps/vpay-sdk 0.2.1

package/dist/resources/checkout-sessions.d.ts

@@ -0,0 +1,55 @@
+/**
+ * `/v1/checkout/sessions` — the four merchant operations Step 9's wire
+ * contract defines, and the one thing this file does that no other resource
+ * does: it redacts the object's `client_secret` from `util.inspect`.
+ *
+ * ADR-0015's matrix records, as a dated gap, that `PaymentIntent` is a plain
+ * interface here and so `console.log(intent)` prints a live payer
+ * credential, while the Rust SDK's hand-written `Debug` redacts it. That gap
+ * is not repeated for a **new** object: every `CheckoutSession` this SDK
+ * hands back carries a custom inspect representation that prints
+ * `[N chars redacted]` in place of the secret, which is exactly what
+ * `vpay_sdk::CheckoutSession`'s `impl Debug` prints.
+ *
+ * `JSON.stringify` is deliberately **not** redacted, and that asymmetry is
+ * the same one Rust has (`Debug` redacts, `Serialize` does not): an embedded
+ * integration must serialise the secret to get it to the browser at all, so
+ * a redacting `toJSON` would break the one thing the field exists for. The
+ * hazard being closed here is the accidental one — a session that reaches a
+ * log line because something logged the whole object.
+ */
+import type { HttpClient } from "../http.js";
+import type { CheckoutSession, CreateCheckoutSessionParams, List, ListCheckoutSessionsParams, RequestOptions } from "../types.js";
+/** `client.checkout.sessions` — see {@link CheckoutResource}. */
+export declare class CheckoutSessionsResource {
+    #private;
+    constructor(http: HttpClient);
+    /**
+     * `POST /v1/checkout/sessions`. Answers the session **with**
+     * `client_secret`, and with `url` when `ui_mode` is `hosted`.
+     */
+    create(params: CreateCheckoutSessionParams, options?: RequestOptions): Promise<CheckoutSession>;
+    /** `GET /v1/checkout/sessions/{id}`. Answers the session with `client_secret`. */
+    retrieve(id: string): Promise<CheckoutSession>;
+    /** `GET /v1/checkout/sessions`. List items never carry `client_secret`. */
+    list(params?: ListCheckoutSessionsParams): Promise<List<CheckoutSession>>;
+    /**
+     * `POST /v1/checkout/sessions/{id}/expire`. `open` → `expired`; a session
+     * whose intent already has a live charge is refused `409`.
+     */
+    expire(id: string, options?: RequestOptions): Promise<CheckoutSession>;
+}
+/**
+ * `client.checkout` — a namespace, not a resource with operations of its
+ * own.
+ *
+ * It exists so the call reads `client.checkout.sessions.create(…)`, which is
+ * the path the wire contract uses (`/v1/checkout/sessions`) and the shape
+ * `vpay_sdk`'s `client.checkout().sessions()` mirrors. A flat
+ * `client.checkoutSessions` would have been shorter and would have made the
+ * two SDKs read differently for the same route.
+ */
+export declare class CheckoutResource {
+    readonly sessions: CheckoutSessionsResource;
+    constructor(http: HttpClient);
+}

package/dist/resources/checkout-sessions.js

@@ -0,0 +1,127 @@
+const INSPECT_CUSTOM = Symbol.for("nodejs.util.inspect.custom");
+/**
+ * The `url` of a hosted session with its fragment redacted.
+ *
+ * D6 puts the session's `client_secret` in the hosted page's URL fragment
+ * (`https://checkout.example/c/cs_1#cs_1_secret_…`), so redacting
+ * `client_secret` alone and printing `url` verbatim would leak exactly the
+ * value the redaction exists to hide — measured, not assumed: the first
+ * version of this file did that, and the test that now pins it failed.
+ */
+function redactUrlFragment(url) {
+    const hash = url.indexOf("#");
+    if (hash === -1) {
+        return url;
+    }
+    const fragment = url.slice(hash + 1);
+    return `${url.slice(0, hash + 1)}[${fragment.length} chars redacted]`;
+}
+/**
+ * Attaches a redacting `util.inspect` representation to one decoded
+ * session, in place.
+ *
+ * Non-enumerable, so the property is invisible to `Object.keys`,
+ * `JSON.stringify`, spread and deep-equality — the object a merchant
+ * receives is still, in every observable way, the decoded response body.
+ * The representation itself is built from a **spread copy**, which does not
+ * carry the symbol, so `inspect` inside it cannot recurse.
+ */
+function withRedactedInspect(session) {
+    if (typeof session !== "object" || session === null) {
+        return session;
+    }
+    Object.defineProperty(session, INSPECT_CUSTOM, {
+        value: function redactedInspect(depth, options, inspect) {
+            const secret = this.client_secret;
+            const copy = { ...this };
+            if (typeof secret === "string") {
+                copy["client_secret"] = `[${secret.length} chars redacted]`;
+            }
+            const url = copy["url"];
+            if (typeof url === "string") {
+                copy["url"] = redactUrlFragment(url);
+            }
+            // `inspect` is handed in by `node:util` itself, so this works
+            // whatever options the caller passed (colours, depth, breakLength)
+            // without this file importing `node:util` at all.
+            return `CheckoutSession ${inspect(copy, options)}`;
+        },
+        enumerable: false,
+        writable: false,
+        configurable: true,
+    });
+    return session;
+}
+/** `client.checkout.sessions` — see {@link CheckoutResource}. */
+export class CheckoutSessionsResource {
+    #http;
+    constructor(http) {
+        this.#http = http;
+    }
+    /**
+     * `POST /v1/checkout/sessions`. Answers the session **with**
+     * `client_secret`, and with `url` when `ui_mode` is `hosted`.
+     */
+    async create(params, options) {
+        // Field order is the wire order the Rust SDK pins byte for byte
+        // (`sdks/rust/tests/resources.rs`); an unset field is omitted from the
+        // body entirely, because `success_url=` and no `success_url` are
+        // different requests and only the second means "not applicable".
+        const body = {
+            payment_intent: params.payment_intent,
+        };
+        if (params.ui_mode !== undefined) {
+            body["ui_mode"] = params.ui_mode;
+        }
+        if (params.success_url !== undefined) {
+            body["success_url"] = params.success_url;
+        }
+        if (params.cancel_url !== undefined) {
+            body["cancel_url"] = params.cancel_url;
+        }
+        if (params.return_url !== undefined) {
+            body["return_url"] = params.return_url;
+        }
+        if (params.customer !== undefined) {
+            body["customer"] = params.customer;
+        }
+        return withRedactedInspect(await this.#http.request("POST", "/checkout/sessions", body, options));
+    }
+    /** `GET /v1/checkout/sessions/{id}`. Answers the session with `client_secret`. */
+    async retrieve(id) {
+        return withRedactedInspect(await this.#http.request("GET", `/checkout/sessions/${encodeURIComponent(id)}`));
+    }
+    /** `GET /v1/checkout/sessions`. List items never carry `client_secret`. */
+    async list(params) {
+        const page = await this.#http.request("GET", "/checkout/sessions", params);
+        if (Array.isArray(page?.data)) {
+            for (const session of page.data) {
+                withRedactedInspect(session);
+            }
+        }
+        return page;
+    }
+    /**
+     * `POST /v1/checkout/sessions/{id}/expire`. `open` → `expired`; a session
+     * whose intent already has a live charge is refused `409`.
+     */
+    async expire(id, options) {
+        return withRedactedInspect(await this.#http.request("POST", `/checkout/sessions/${encodeURIComponent(id)}/expire`, {}, options));
+    }
+}
+/**
+ * `client.checkout` — a namespace, not a resource with operations of its
+ * own.
+ *
+ * It exists so the call reads `client.checkout.sessions.create(…)`, which is
+ * the path the wire contract uses (`/v1/checkout/sessions`) and the shape
+ * `vpay_sdk`'s `client.checkout().sessions()` mirrors. A flat
+ * `client.checkoutSessions` would have been shorter and would have made the
+ * two SDKs read differently for the same route.
+ */
+export class CheckoutResource {
+    sessions;
+    constructor(http) {
+        this.sessions = new CheckoutSessionsResource(http);
+    }
+}

package/dist/resources/customers.d.ts

@@ -0,0 +1,97 @@
+/**
+ * `/v1/customers` — the five merchant operations on the Customer object
+ * (S4a), and the one thing this file does that no other resource does: it
+ * distinguishes *clear this field* from *leave it alone* — for four fields
+ * now, `address` included. `address` is also the one field on this API that
+ * is WIDER than Stripe's: it carries the GPS point beside the six formal
+ * components (the maintainer, 2026-09-11), and `Address` in `types.ts` says
+ * why — including why the coordinate is a whole count of microdegrees and
+ * never a decimal degree.
+ *
+ * # The three states, and why `update` looks the way it does
+ *
+ * `undefined` (or an absent key) means "leave it alone"; a string means "set
+ * it"; **`null` means "clear it"**, and this file sends that as `name=`,
+ * which is what the wire spells "clear". Collapsing `null` and `undefined` —
+ * the obvious simplification, and what a `params.name !== undefined` guard
+ * alone would do — makes a payer's email unclearable through the API that
+ * documents how to clear it. `sdks/rust`'s `UpdateCustomerParams` uses
+ * `Option<Option<String>>` for exactly this and the server carries the same
+ * three states in `vpay_db::CustomerPatch`.
+ *
+ * # No redacting `util.inspect`, unlike `checkout-sessions.ts`
+ *
+ * That file redacts because a `CheckoutSession` carries a *credential*:
+ * printing one is a compromise, and the merchant who logged it can do nothing
+ * about it afterwards. A `Customer` carries a payer's own name, email and
+ * phone number — data the merchant collected, already holds and is
+ * responsible for. Redacting it here would hide their own data from them
+ * while doing nothing about the copy in their database.
+ *
+ * The place that judgement is made *for* them is the server: vpay's
+ * `CustomerRow` redacts all three in its `Debug`, because vpay's logs are not
+ * the merchant's. `docs/flows/customers.md` records the asymmetry so it reads
+ * as a decision rather than an oversight, and `sdks/rust`'s `Customer`
+ * derives `Debug` for the same reason.
+ */
+import type { HttpClient } from "../http.js";
+import type { CreateCustomerParams, Customer, DeletedCustomer, List, ListCustomersParams, RequestOptions, UpdateCustomerParams } from "../types.js";
+/** `client.customers` — see {@link CustomersResource}. */
+export declare class CustomersResource {
+    #private;
+    constructor(http: HttpClient);
+    /**
+     * `POST /v1/customers`.
+     *
+     * Field order is the wire order the Rust SDK pins byte for byte
+     * (`sdks/rust/tests/resources.rs`); an unset field is omitted from the body
+     * entirely, because `name=` and no `name` are different requests and only
+     * the second means "not applicable".
+     */
+    create(params: CreateCustomerParams, options?: RequestOptions): Promise<Customer>;
+    /** `GET /v1/customers/{id}`. */
+    retrieve(id: string): Promise<Customer>;
+    /**
+     * `POST /v1/customers/{id}` — the update.
+     *
+     * A `POST` and not a `PUT`/`PATCH`, because that is what the API is:
+     * Stripe has neither verb, and a merchant's existing client sends a `POST`.
+     *
+     * A patch that would clear the customer's **last** identifier is refused
+     * `400` naming `name` — a customer must always have one of `name`, `email`
+     * and `phone`.
+     */
+    update(id: string, params: UpdateCustomerParams, options?: RequestOptions): Promise<Customer>;
+    /** `GET /v1/customers`. */
+    list(params?: ListCustomersParams): Promise<List<Customer>>;
+    /**
+     * `DELETE /v1/customers/{id}` — an **erasure**, in one of two shapes.
+     *
+     * `del` and not `delete`: `delete` is a reserved word in older JavaScript
+     * object literals, which is why Stripe's own SDKs spell it this way, and
+     * `sdks/rust`'s `CustomersResource::del` matches so a merchant who read one
+     * SDK's docs can use the other.
+     *
+     * A customer with **no payment history** is removed outright: a subsequent
+     * {@link retrieve} answers the same 404 as an id that never existed.
+     *
+     * A customer any PaymentIntent, Checkout Session or Invoice references
+     * cannot be removed — vpay keeps a payment attached to the payer it was
+     * taken from — so it is **anonymised** instead. The row and the payment
+     * record stay; every identifier on the customer becomes `[redacted]`, and
+     * so does every copy vpay kept elsewhere. A later {@link retrieve} answers
+     * `200` with {@link Customer.deleted} `true`, so your own stored `cus_…`
+     * keeps resolving. `metadata` is untouched: that is your data, not the
+     * payer's.
+     *
+     * Either way this answers `{deleted: true}`, and a second call is a no-op
+     * rather than a second erasure. Until 2026-09-10 the second case answered
+     * `409` instead, with advice — clear `name`, `email` and `phone` — that the
+     * server's own one-of rule refuses.
+     *
+     * Carries an `Idempotency-Key` like every other write on this API, which is
+     * what makes a retried delete answer the original `{deleted: true}` rather
+     * than a `404`.
+     */
+    del(id: string, options?: RequestOptions): Promise<DeletedCustomer>;
+}

package/dist/resources/customers.js

@@ -0,0 +1,157 @@
+/**
+ * One patch field, in the wire's own three-state encoding.
+ *
+ * Returns `undefined` for "the request did not mention this", which the
+ * caller drops from the body entirely, and the empty string for "clear it".
+ */
+function patch(value) {
+    if (value === undefined) {
+        return undefined;
+    }
+    return value === null ? "" : value;
+}
+/**
+ * The eight address components as a nested body value, with every unset one
+ * omitted entirely.
+ *
+ * Omitted and not sent empty, because on this API those are different
+ * requests everywhere else — and because the server replaces the address
+ * whole, so an omitted component is cleared either way and `address[city]=`
+ * would only add a pair saying the same thing.
+ *
+ * The two coordinate keys go through the same loop as the six formal ones and
+ * are typed `number` rather than `string`: the form encoder renders a number
+ * as a decimal integer with no separators and refuses a non-finite one
+ * (`form.ts`), so there is no path from this function to a body carrying a
+ * float — which is the whole of why the wire field is named for its unit.
+ */
+function addressBody(address) {
+    const body = {};
+    for (const key of [
+        "line1",
+        "line2",
+        "city",
+        "state",
+        "postal_code",
+        "country",
+        "latitude_microdeg",
+        "longitude_microdeg",
+    ]) {
+        const value = address[key];
+        if (value !== undefined) {
+            body[key] = value;
+        }
+    }
+    return body;
+}
+/** `client.customers` — see {@link CustomersResource}. */
+export class CustomersResource {
+    #http;
+    constructor(http) {
+        this.#http = http;
+    }
+    /**
+     * `POST /v1/customers`.
+     *
+     * Field order is the wire order the Rust SDK pins byte for byte
+     * (`sdks/rust/tests/resources.rs`); an unset field is omitted from the body
+     * entirely, because `name=` and no `name` are different requests and only
+     * the second means "not applicable".
+     */
+    async create(params, options) {
+        const body = {};
+        if (params.name !== undefined) {
+            body["name"] = params.name;
+        }
+        if (params.email !== undefined) {
+            body["email"] = params.email;
+        }
+        if (params.phone !== undefined) {
+            body["phone"] = params.phone;
+        }
+        if (params.address !== undefined) {
+            body["address"] = addressBody(params.address);
+        }
+        if (params.metadata !== undefined) {
+            body["metadata"] = params.metadata;
+        }
+        return this.#http.request("POST", "/customers", body, options);
+    }
+    /** `GET /v1/customers/{id}`. */
+    async retrieve(id) {
+        return this.#http.request("GET", `/customers/${encodeURIComponent(id)}`);
+    }
+    /**
+     * `POST /v1/customers/{id}` — the update.
+     *
+     * A `POST` and not a `PUT`/`PATCH`, because that is what the API is:
+     * Stripe has neither verb, and a merchant's existing client sends a `POST`.
+     *
+     * A patch that would clear the customer's **last** identifier is refused
+     * `400` naming `name` — a customer must always have one of `name`, `email`
+     * and `phone`.
+     */
+    async update(id, params, options) {
+        const body = {};
+        const name = patch(params.name);
+        if (name !== undefined) {
+            body["name"] = name;
+        }
+        const email = patch(params.email);
+        if (email !== undefined) {
+            body["email"] = email;
+        }
+        const phone = patch(params.phone);
+        if (phone !== undefined) {
+            body["phone"] = phone;
+        }
+        if (params.address !== undefined) {
+            // `address=` — the wire's own "remove this", the same spelling `name=`
+            // uses. NOT eight empty components: the server reads a *scalar* `address`
+            // as the clear, and one spelling means a merchant reading the body sees
+            // what they asked for.
+            body["address"] =
+                params.address === null ? "" : addressBody(params.address);
+        }
+        if (params.metadata !== undefined) {
+            body["metadata"] = params.metadata;
+        }
+        return this.#http.request("POST", `/customers/${encodeURIComponent(id)}`, body, options);
+    }
+    /** `GET /v1/customers`. */
+    async list(params) {
+        return this.#http.request("GET", "/customers", params);
+    }
+    /**
+     * `DELETE /v1/customers/{id}` — an **erasure**, in one of two shapes.
+     *
+     * `del` and not `delete`: `delete` is a reserved word in older JavaScript
+     * object literals, which is why Stripe's own SDKs spell it this way, and
+     * `sdks/rust`'s `CustomersResource::del` matches so a merchant who read one
+     * SDK's docs can use the other.
+     *
+     * A customer with **no payment history** is removed outright: a subsequent
+     * {@link retrieve} answers the same 404 as an id that never existed.
+     *
+     * A customer any PaymentIntent, Checkout Session or Invoice references
+     * cannot be removed — vpay keeps a payment attached to the payer it was
+     * taken from — so it is **anonymised** instead. The row and the payment
+     * record stay; every identifier on the customer becomes `[redacted]`, and
+     * so does every copy vpay kept elsewhere. A later {@link retrieve} answers
+     * `200` with {@link Customer.deleted} `true`, so your own stored `cus_…`
+     * keeps resolving. `metadata` is untouched: that is your data, not the
+     * payer's.
+     *
+     * Either way this answers `{deleted: true}`, and a second call is a no-op
+     * rather than a second erasure. Until 2026-09-10 the second case answered
+     * `409` instead, with advice — clear `name`, `email` and `phone` — that the
+     * server's own one-of rule refuses.
+     *
+     * Carries an `Idempotency-Key` like every other write on this API, which is
+     * what makes a retried delete answer the original `{deleted: true}` rather
+     * than a `404`.
+     */
+    async del(id, options) {
+        return this.#http.request("DELETE", `/customers/${encodeURIComponent(id)}`, undefined, options);
+    }
+}

package/dist/resources/events.d.ts

@@ -0,0 +1,8 @@
+import type { HttpClient } from "../http.js";
+import type { Event, List, ListEventsParams } from "../types.js";
+/** `/v1/events` — docs/flows/merchant-auth.md, "Resources". */
+export declare class EventsResource {
+    #private;
+    constructor(http: HttpClient);
+    list(params?: ListEventsParams): Promise<List<Event>>;
+}

package/dist/resources/events.js

@@ -0,0 +1,10 @@
+/** `/v1/events` — docs/flows/merchant-auth.md, "Resources". */
+export class EventsResource {
+    #http;
+    constructor(http) {
+        this.#http = http;
+    }
+    async list(params) {
+        return this.#http.request("GET", "/events", params);
+    }
+}

package/dist/resources/invoices.d.ts

@@ -0,0 +1,193 @@
+/**
+ * `/v1/invoices` and `/v1/invoice_items` — the thirteen merchant operations
+ * on the Invoice object and its lines (S4b).
+ *
+ * # The one thing to know before calling any of them
+ *
+ * **The state machine is the server's `WHERE` clause, not a check this SDK
+ * makes.** A transition that does not apply comes back a `409` naming the
+ * invoice's current status, and this SDK does not try to predict which —
+ * `draft → open → paid | void | uncollectible`, and every method below says
+ * which statuses it accepts. Reading the invoice first to decide whether to
+ * call is a race; call, and read the refusal.
+ *
+ * # Two resources, one file
+ *
+ * A line has no life of its own: it belongs to exactly one invoice, its
+ * currency and tenant are copied off that invoice, and every write to it is
+ * refused once the invoice is issued. Splitting the two would put that guard
+ * in a file that does not mention the thing it guards. `sdks/rust` keeps them
+ * in one module for the same reason.
+ */
+import type { HttpClient } from "../http.js";
+import type { CreateInvoiceItemParams, CreateInvoiceParams, DeletedInvoice, DeletedInvoiceItem, Invoice, InvoiceLine, List, ListInvoicesParams, PayInvoiceParams, RequestOptions, UpdateInvoiceItemParams, UpdateInvoiceParams } from "../types.js";
+/** `client.invoices` — see the module doc. */
+export declare class InvoicesResource {
+    #private;
+    constructor(http: HttpClient);
+    /**
+     * `POST /v1/invoices` — creates a **draft**, with no number and zero
+     * amounts.
+     *
+     * Field order is the wire order `sdks/rust/tests/resources.rs` pins byte
+     * for byte; an unset field is omitted from the body entirely, because
+     * `description=` and no `description` are different requests and only the
+     * second means "not applicable".
+     *
+     * A `400` naming `customer` when it is absent, unknown, or another
+     * merchant's — one sentence for all three, so the parameter is not an
+     * oracle; and a `400` naming `currency` for one this deployment does not
+     * settle.
+     */
+    create(params: CreateInvoiceParams, options?: RequestOptions): Promise<Invoice>;
+    /**
+     * `GET /v1/invoices/{id}` — the invoice **with its lines**.
+     *
+     * This is the read a webhook handler falls back to: an `invoice.*` event
+     * body carries an empty `lines.data`, and this response always carries the
+     * lines.
+     *
+     * Another merchant's `in_…` is the same `404`, byte for byte, as one that
+     * never existed.
+     */
+    retrieve(id: string): Promise<Invoice>;
+    /**
+     * `POST /v1/invoices/{id}` — patches a **draft**.
+     *
+     * A `POST` and not a `PATCH`, for `customers.update`'s reason, even though
+     * the server mounts both verbs on the one handler: `POST` is what a
+     * merchant's existing Stripe client sends, so it is the one that has to
+     * work.
+     *
+     * A `409` naming the status once the invoice is no longer a draft — an
+     * issued document's terms are what was sent to the payer. Void it and issue
+     * a new one.
+     */
+    update(id: string, params: UpdateInvoiceParams, options?: RequestOptions): Promise<Invoice>;
+    /** `GET /v1/invoices` — newest first. */
+    list(params?: ListInvoicesParams): Promise<List<Invoice>>;
+    /**
+     * `DELETE /v1/invoices/{id}` — **draft only**, and its lines go with it.
+     *
+     * An issued invoice is {@link InvoicesResource.void}ed, never deleted: a
+     * voided draft would be a non-draft row with no number, which the database
+     * refuses outright, and a document that vanished is a hole an accountant
+     * reads as a destroyed one.
+     *
+     * `del` and not `delete`, for `customers.del`'s reason. Carries an
+     * `Idempotency-Key` like every other write, which is what makes a retried
+     * delete answer the original `{deleted: true}` rather than a `404`.
+     */
+    del(id: string, options?: RequestOptions): Promise<DeletedInvoice>;
+    /**
+     * `POST /v1/invoices/{id}/finalize` — issues the document. **Draft only.**
+     *
+     * The money transition: the invoice takes the next number out of this
+     * merchant's own sequence under a row lock, its lines freeze, its amounts
+     * are computed once, and it moves to `"open"` — all in one transaction,
+     * with `invoice.finalized` inside it. Numbers are consecutive and have no
+     * holes, unlike Stripe's.
+     *
+     * A `400` naming `invoice` when it has no lines, or when its total is past
+     * `Number.MAX_SAFE_INTEGER` minor units; a `409` when it is not a draft.
+     */
+    finalize(id: string, options?: RequestOptions): Promise<Invoice>;
+    /**
+     * `POST /v1/invoices/{id}/void` — cancels an issued document. **Open
+     * only.**
+     *
+     * The invoice **keeps its number**. Terminal.
+     *
+     * A `409` when it is not open, and a `409` while a payment intent is
+     * attached and not yet canceled — cancel that intent first.
+     */
+    void(id: string, options?: RequestOptions): Promise<Invoice>;
+    /**
+     * `POST /v1/invoices/{id}/mark_uncollectible` — writes an issued document
+     * off. **Open only.**
+     *
+     * Still owed, never expected. Terminal, and it **emits no event**: vpay
+     * does not write `invoice.marked_uncollectible`, so nothing arrives on a
+     * webhook and a merchant reconciling write-offs reads them with
+     * `list({ status: "uncollectible" })`.
+     *
+     * # `markUncollectible` here, `mark_uncollectible` in `sdks/rust`
+     *
+     * The only capability the two SDKs spell differently, and the difference is
+     * each language's own casing rather than a divergence: `sdks/rust` may not
+     * spell `markUncollectible` (`non_snake_case` is a rustc lint, not a
+     * preference) and this package should not spell `mark_uncollectible` —
+     * Stripe's own Node SDK, which merchants arrive from, says
+     * `markUncollectible`, and the other spelling would be the one snake_case
+     * method in a camelCase package.
+     *
+     * [ADR-0015](../../../docs/adr/0015-sdk-parity.md) decision 1 is that
+     * parity is **per capability, not per method name**, and its alternatives
+     * reject method-name parity in as many words. Until 2026-09-08
+     * `verify-sdk-parity` could not express that — it keyed a row on one
+     * spelling — and this method was named `mark_uncollectible` to satisfy the
+     * gate. It is `markUncollectible` now because the gate learned the
+     * distinction instead: `PARITY_COLUMN_SPELLINGS` in `.xtask/src/main.rs`
+     * carries the one entry, and an entry that exempts nothing fails the build.
+     */
+    markUncollectible(id: string, options?: RequestOptions): Promise<Invoice>;
+    /**
+     * `POST /v1/invoices/{id}/pay` — mints a payment intent and a hosted
+     * checkout for what is left. **Open only.**
+     *
+     * **This does not charge anybody.** Stripe's `pay` charges a stored payment
+     * method; vpay has none, so this answers the invoice with
+     * {@link Invoice.payment_intent} and {@link Invoice.hosted_invoice_url}
+     * set — a page to send the payer to. The invoice stays `"open"` until the
+     * settlement moves it, which is when `invoice.paid` is emitted.
+     *
+     * One payment at a time: calling this again while the attached intent is
+     * live is a `409`, and cancelling that intent is the way back. Two
+     * concurrent calls attach exactly one intent.
+     *
+     * A `500 checkout_not_configured` when this deployment serves no checkout
+     * page.
+     */
+    pay(id: string, params: PayInvoiceParams, options?: RequestOptions): Promise<Invoice>;
+}
+/**
+ * `client.invoiceItems` — the four operations on `/v1/invoice_items`: the
+ * lines of a **draft** invoice.
+ *
+ * There is deliberately no `list`: an invoice's lines are read off the
+ * invoice ({@link Invoice.lines}, expanded on every render), and a
+ * merchant-wide list of lines across invoices answers no question anybody
+ * asked. The server mounts no collection `GET` either, so this is not an
+ * omission here.
+ *
+ * Every write requires the parent to still be a `"draft"`;
+ * {@link InvoiceItemsResource.retrieve} does not.
+ */
+export declare class InvoiceItemsResource {
+    #private;
+    constructor(http: HttpClient);
+    /**
+     * `POST /v1/invoice_items` — adds a line to a draft, and the invoice's
+     * `amount_due` moves with it.
+     *
+     * Throws `TypeError` before any request when `unit_amount` is not a
+     * non-negative safe integer; a `400` naming `invoice` when it is not one of
+     * your drafts.
+     */
+    create(params: CreateInvoiceItemParams, options?: RequestOptions): Promise<InvoiceLine>;
+    /** `GET /v1/invoice_items/{id}` — readable whatever the parent's status. */
+    retrieve(id: string): Promise<InvoiceLine>;
+    /**
+     * `POST /v1/invoice_items/{id}` — **draft parent only**, with `amount`
+     * recomputed.
+     *
+     * Throws `TypeError` before any request for a `unit_amount` outside the
+     * bound; a `409` once the parent is no longer a draft.
+     */
+    update(id: string, params: UpdateInvoiceItemParams, options?: RequestOptions): Promise<InvoiceLine>;
+    /**
+     * `DELETE /v1/invoice_items/{id}` — **draft parent only**, and the invoice
+     * re-totals.
+     */
+    del(id: string, options?: RequestOptions): Promise<DeletedInvoiceItem>;
+}