Dynamic Terminal Selection for Juicebox V5 Payments

Problem

When paying a Juicebox V5 project, users may want to pay with tokens (e.g., USDC) that the project doesn't directly accept in its accounting context. Sending such payments to JBMultiTerminal results in a JBMultiTerminal_TokenNotAccepted(token) revert.

Common symptom: Transaction simulation shows "likely to fail" after permit2 signing, with the TokenNotAccepted error in Tenderly or other simulation tools.

Context / Trigger Conditions

Apply this pattern when:

• Building a payment UI that supports multiple tokens (ETH, USDC, etc.)
• A project uses ETH accounting context but users want to pay with USDC
• You see JBMultiTerminal_TokenNotAccepted errors in transaction simulations
• MetaMask shows "This transaction is likely to fail" after permit2 signing
• You need to determine which terminal to use at runtime