Added
01 September 2026
2 days ago
🌐 New Routes
- USD international wire payouts. You can now wire USD to a beneficiary bank outside the US. Create the payout method with
type: "usdInternationalWire"onPOST /api/counterparties/{id}/payout-methods, addressing the beneficiary bank byswiftBicand supplyingbankNameandbankAccountNumber(an account number or IBAN). SupplyintermediaryRoutingNumberwhen the beneficiary bank requires a named correspondent bank. This is enabled per organization — reach out to [email protected] if you want it turned on.
⭐ Enhancements
- Compliance API — offshore jurisdictions are now supported for business compliance reviews. Cayman Islands, British Virgin Islands, Bermuda, Turks and Caicos, Anguilla, Jersey, Guernsey, Isle of Man, Gibraltar, and Mauritius now have tax ID allowlists. Jurisdictions that issue no standard TIN accept the Company/Registration Number (
CRN); the Crown dependencies and Gibraltar acceptCRNandTIN. A country with no allowlist entry no longer fails every tax ID type at submission. See Upload attestations. - Payouts API — developer fees are now rejected up front for organizations without a parent. Payouts carrying
developerFee.developerFeePercentageare validated onPOST /api/payouts/payoutand return400when the paying organization has no parent organization. Retry on behalf of a child organization using theon-behalf-ofheader. Eligibility follows the paying organization's actual parent rather than the header, so a child organization calling with its own API key can still collect developer fees. AdeveloperFeePercentageof0counts as no developer fee and is unaffected. - Accounts API — set settlement strategy returns
412instead of500for unsupported organizations.PUT /api/accounts/{id}/set-settlement-strategynow returns a typedSettlementStrategyNotSupportedExceptionwhen the organization's provider does not support settlement strategies, or when the organization is not approved for that provider, instead of an internal server error.
🐛 Bug Fixes
- Compliance API — address validation no longer flags cosmetic differences as corrections. An address that Google merely reformats (ZIP+4 expansion, inferred administrative regions, casing or punctuation) no longer produces a
SUGGESTED_CORRECTIONwarning on attestation upload. Only material corrections, such as a replaced postal code, are surfaced.