Process multiple refund decisions efficiently with the Arbiter SDK
The Arbiter SDK provides batch operations for processing multiple refund requests in a single call. Both batchApprove and batchDeny accept an array of { paymentInfo, nonce } objects.
Batch items are processed sequentially, not atomically. If one item fails mid-batch, all previously processed items will not be rolled back. Design your error handling accordingly.
Each item in the batch array must include both the paymentInfo struct and the nonce:
Copy
interface BatchItem { /** The full PaymentInfo struct identifying the payment */ paymentInfo: PaymentInfo; /** The record index (nonce) from PaymentIndexRecorder */ nonce: bigint;}
The nonce identifies which specific charge record the refund request targets. For most single-charge payments, this is 0n.
Each item in a batch results in a separate on-chain transaction. Gas costs scale linearly with the number of items. Plan batch sizes around your RPC provider’s rate limits.
Factor
Detail
Transaction ordering
Items are processed sequentially to ensure correct nonce ordering.
Gas costs
Each item is a separate transaction. Batch methods save on SDK overhead, not gas.
Partial failures
If one transaction fails, previous ones remain on-chain. Handle partial failures in your logic.
Rate limiting
Large batches may hit RPC rate limits. Consider adding delays for 50+ item batches.