Say that an Interac destination needs no institution

changelog.md

@@ -2,6 +2,14 @@
 
 Notable changes to the Unigox partner API, newest first.
 
+## 2026-09-15
+
+**Interac e-Transfer no longer asks for an `institution_id` the catalog said it did not need.** `/api/v1/supported/payment-rails` reports `institution_required: false` for `interac-e-transfer` — an e-Transfer is addressed to the recipient's email or phone number, not to a bank you pick — but creating a destination on it without an `institution_id` failed with `institution_id is required for this rail`. A partner following the catalog was refused, which was our bug, the same one fixed for the Chinese wallet rails on 2026-08-28.
+
+- Omitting `institution_id` on `interac-e-transfer` now works. The destination resolves to `interac-e-transfers` and goes through the same checks as if you had named it.
+- Sending an `institution_id` is still accepted: `interac-e-transfers`, or any bank `/api/v1/supported/institutions?rail=interac-e-transfer` lists.
+- Destinations you already created are unchanged.
+
 ## 2026-09-14
 
 **An on-ramp order can now be paid from the fiat account you issued the customer.** Instead of wiring the order's fiat to a vendor and calling `confirm-payment-sent`, the customer transfers the amount into their own account and the order moves on by itself.

openapi/swagger.yaml

@@ -408,9 +408,15 @@ paths:
         Current partner API omission support is explicitly available for:
         - `iban-sepa`
         - `nip-nigeria`
+        - `faster-payments`
         - `imps-neft-india`
+        - `alipay-wallet`
+        - `wechat-wallet`
+        - `interac-e-transfer`
 
-        For `iban-sepa` and `nip-nigeria`, partners may omit `institution_id` and the backend resolves the generic `other-bank` payment method automatically.
+        For `iban-sepa`, `nip-nigeria` and `faster-payments`, partners may omit `institution_id` and the backend resolves the generic `other-bank` payment method automatically.
+
+        For `alipay-wallet`, `wechat-wallet` and `interac-e-transfer`, an omitted `institution_id` resolves to the rail's own institution (`alipay`, `wechat-pay`, `interac-e-transfers`), which goes through the same checks as if you had sent it. An Interac e-Transfer is addressed to the recipient's `email` or `phone`, not to a bank.
 
         `imps-neft-india` returns `institution_required: false` and has **no** `institution_id` field: the IFSC code encodes both bank and branch and routes the payout on its own. Required fields are `bank_name`, `ifsc_code`, `account_number`, and `full_name`. Sending `institution_id` is accepted but ignored (it resolves to the generic `imps-or-neft-transfer` method); the receiving bank comes from `bank_name` + `ifsc_code`.
 
@@ -1698,11 +1704,12 @@ paths:
 
         Institution handling:
         - for most rails, `institution_id` must be provided from `/api/v1/supported/institutions`
-        - partners may omit `institution_id` only for the explicitly supported rails below; the backend will assign the generic `other-bank` payment method automatically
+        - partners may omit `institution_id` only for the explicitly supported rails below
 
         Currently supported omission rails:
-        - `iban-sepa`
-        - `nip-nigeria`
+        - `iban-sepa`, `nip-nigeria`, `faster-payments` — resolve to the generic `other-bank` payment method
+        - `imps-neft-india` — resolves to the generic `imps-or-neft-transfer` method; the bank comes from `bank_name` + `ifsc_code`
+        - `alipay-wallet`, `wechat-wallet`, `interac-e-transfer` — resolve to the rail's own institution (`alipay`, `wechat-pay`, `interac-e-transfers`) and go through the same checks as if you had sent it
       operationId: createPaymentDetails
       security:
         - ApiKeyAuth: []