[annvelents]

Context

Wallet top-ups produce credit invoices. A wallet can now carry its own payment term, overriding the customer and billing entity terms on every top-up invoice.

Linear: BIL-522. Unblocks the frontend work in BIL-675. The wallets.payment_term column was added in #6231.

Description

Resolution. Every top-up path (manual, interval, threshold, API) goes through Invoices::PaidCreditService.

• Wallet has a term: the credit invoice snapshots it with payment_term_source: "wallet".
• No wallet term: resolution is unchanged: customer → issuing billing entity → due_on_receipt.

The term lives on the wallet only. Recurring rules and individual transactions have no term of their own.

Payment-gated top-ups (invoice_requires_successful_payment) keep today's behaviour, per the product decision. FinalizeOpenCreditService moves both the issuing date and the due date to the payment day, and leaves the term snapshot untouched. A spec pins this.

Writes and reads.

• Wallets::CreateService and UpdateService validate and store the normalized payment_term. On update, null clears it.
• POST /api/v1/wallets, PUT /api/v1/wallets/:id and the customer-scoped wallet endpoints accept payment_term, through RawPaymentTermParams.
• The wallet serializer returns payment_term: the wallet's own term, or null when it inherits. The wallet.* webhooks gain the field.
• The createCustomerWallet and updateCustomerWallet mutations accept paymentTerm. Wallet.paymentTerm resolves through PaymentTerm.from_h.

Validation

Specs cover:

• credit invoices with and without a wallet term;
• the payment-gated finalization pin;
• service create, update, clear and invalid input;
• REST create and update, through the shared wallet endpoint examples;
• the serializer;
• GraphQL create, update and clear.

---

🤖 Generated with Claude Code