Second factor to authorize the operation with. Which value is valid — and
whether the field is needed at all — depends on the sending bank and on the
payroll transition you are calling, so send the one your bank uses for that
step.
Cardda pre-validates the combination before touching the bank; one it does not
accept is rejected with 422 {"message": "Invalid authorization parameters"}.
| Bank | enroll | preauthorize | authorize |
|---|
| Banco de Chile | digipass + token (6–12 digits) or device + device_id — not required at all when the payroll is deferred (online: false) | digipass + token (6–12 digits) or device + device_id | digipass + token (6–12 digits) or device + device_id |
| BCI | not required | not required | multipass + token (6–12 digits) |
| Santander | not required | not required | santander_pass (no token needed) or token + token (6–12 digits) |
| Banco BICE | not required | not required | bice_pass (no token needed) or token + token (6–12 digits) |
| Itaú | not required | not required | not required |
| Scotiabank | token + token (6–12 digits) | token + token (6–12 digits) | token + token (6–12 digits) |
| Banco Security, Banco Internacional | not required | not available — the payroll flow ends at enrollment | not available |
| BCP (Perú) | not available — payrolls are not supported on this bank | not available | not available |
"Not required" means the pre-validation passes with the field absent; sending
it anyway is harmless. "Not available" means the endpoint answers that same
422 for every combination.
itau_pass stays in the enum for backward compatibility: it only carries
meaning on the standalone transfer endpoints
(POST /v1/banking/bank_accounts/{bank_account_id}/authorize), never on a
payroll.
