# v6.8.0 - 2026-08-20

Release notes for Voltage Payments API release `v6.8.0`, published 2026-08-20.

- Added configurable processing fees for supported sends and receives, with separate `send_basis_points` and `receive_basis_points` rates. Wallet policies can override the wallet's current line-of-credit rates, including an explicit zero rate. Rates are fixed when a payment starts.
- Fixed-amount receive requests now include the configured receive processing fee in the amount presented to the payer. Submit only the intended principal: the API calculates the fee and includes it in the generated payment request, while `requested_amount` remains the principal. On sends, the processing fee is charged to the sending wallet in addition to the principal and network fee.
- Payment responses and webhooks now expose optional top-level `processing_fee` terms, including the snapshotted rate and server-calculated amount. Use the returned amount when displaying the fee. These terms are omitted for fee-free payments and historical payments whose original terms cannot be reconstructed.
- Added an optional `payment_breakdown` separating principal, network fees, and processing fees. Payment-level breakdowns aggregate partial receives; payment-scoped wallet ledger entries provide settlement details. For cross-currency payments, use the returned breakdown rather than recalculating fees from the displayed principal. Provisional breakdowns can change as wallet settlement finalizes conversion and rounding.
- Billing line items now expose optional `processing_fees` totals split into send and receive amounts. These are informational accounting totals, separate from the bill amount due and Voltage's volume fee.
- Added `payout_holdback` controls for USD lines of credit. Retain a percentage of each bill's gross ACH payout or enough funds to reach a fixed reserve target in cents. Held-back funds remain in the customer's USD wallets; a holdback is a reserve, not a fee. The default `none` mode preserves full payouts.
- Lightning sends now accept an explicit zero `max_fee` to require a zero-fee route. This limit applies to network/provider fees; configured processing fees are additional.
- Added structured context to supported policy and line-of-credit errors, and recorded payment policy validation failures for subsequent reads.
- Fixed browser cross-origin access to authenticated Checkout settings for configured management origins.

## Integration notes

- Use `processing_fee` for fee configuration. Omitting it leaves the configuration unchanged, an object sets exact rates, and `null` clears it. Clearing a wallet override restores line-of-credit inheritance. Configuration PATCH requests return `202 Accepted`; wait for reads to reflect the change before creating payments that depend on it.
- Processing-fee changes through the public line-of-credit PATCH route are limited to non-Mainnet lines of credit. Mainnet line-of-credit fee changes require administrator access. Wallet processing-fee overrides support all networks. USD payout holdbacks can be updated through the public line-of-credit route, including on Mainnet.
- Fee-configuration PATCH bodies reject unknown keys. The public field name is `processing_fee`; earlier development names such as `customer_fee` are not supported aliases.