/**
 * Invoice payload codec. Telegram echoes the `invoice_payload` string
 * back on `pre_checkout_query` and `successful_payment`; we use it to
 * recover the `(productKey, userId)` pair that the in-flight purchase
 * refers to.
 *
 * Constraints from Telegram:
 *   - Max 128 bytes.
 *   - Must be a string (we use printable ASCII).
 *
 * Format: `${productKey}|${userId}`
 *
 * The `|` delimiter is unambiguous because productKey is one of:
 *   - `vip.${number}`        — only digits and `.`
 *   - `credits.${number}`    — only digits and `.`
 *   - `perks.${key}`         — key restricted to `/^[a-z][a-z0-9_]*$/i`
 *                              by `config.ts` validation
 *
 * None of those contain `|`, so the first `|` is always the delimiter.
 * Worst case length is ~`perks.${64-char-key}|${20-digit-int}` ≈ 90 bytes
 * — comfortably under the 128-byte cap. We assert the length to fail
 * loud if the cap is ever approached.
 */
export type DecodedPayload = {
    readonly productKey: string;
    readonly userId: number;
};
/**
 * Build the `invoice_payload` string for a `sendInvoice` call. Throws
 * `Panic` if the result would exceed Telegram's 128-byte cap — that's
 * either a bad productKey or a userId out of bounds, both of which are
 * bugs we want to scream about.
 */
export declare const encodePayload: (productKey: string, userId: number) => string;
/**
 * Decode the `invoice_payload` Telegram echoes back. Returns `undefined`
 * (NOT throws) on malformed input — Telegram could in principle deliver
 * a payload from a different bot version, and we want the pre_checkout
 * handler to be able to reject it gracefully rather than crashing.
 */
export declare const decodePayload: (payload: string) => DecodedPayload | undefined;
//# sourceMappingURL=payload.d.ts.map