SEK Credit Transfer FAQs

• Legacy: Payments API v1.3.2 (multi-country)
• New:
  • Payments SE Private API v2.0.0
  • Payments SE Corporate API v2.0.0

The Accounts API (v2.1.30) and Subscriptions API (v1.0.22) are not part of this migration.

1. Review the new OpenAPI specifications on the Developer Portal.
2. Subscribe your app to the relevant product (payments-se-private and/or payments-se-corporate) via the Subscriptions API.
3. Develop and test in the Sandbox environment.
4. Use the Go Live process on the Developer Portal when ready for production.

1. Subscribe your existing app to the new products via the Subscriptions API:
   • payments-se-private (PIS scope)
   • payments-se-corporate (PIS scope)
2. Update base URL from /openbanking/psd2/v1 to /openbanking/psd2/se/v2.
3. Split your code paths by customer segment (private vs corporate).
4. Map your product calls to the new endpoint structure (/single/{product} vs /signing-basket).
5. Adapt payloads to the product-specific schemas — particularly creditorAccount.accountType, chargeBearer, paymentTypeInformation and remittance text patterns.
6. Move SEK Credit Transfer flows into baskets — single sek-credit-transfer is not supported in v2.
7. Re-test SCA flows — both DECOUPLED and REDIRECT are still supported, but URLs and link structures are versioned.
8. Regression-test cancellation flows for future-dated payments.
9. Verify in Sandbox, then complete Go Live on the Developer Portal.

Note the new /se/v2 path segment. The legacy API used /openbanking/psd2/v1.

The new APIs split clearly between customer segment and payment type:

• /payments/private/single/{paymentProduct} — single private payments
• /payments/private/signing-basket — private basket payments
• /payments/corporate/single/{paymentProduct} — single corporate payments
• /payments/corporate/signing-basket — corporate basket payments
• /payments/private/accounts/shorttermconsents — short-term consent (Private only)

In v1.3.2, all payments used a single /payments/{paymentProduct} endpoint regardless of customer type.

Important: In v2, SEKCT can only be executed inside a signing basket — single SEKCT payments are no longer supported. SHBCT, SEPACT and CCCT can only be executed as single payments.

• Dedicated product-specific schemas: each product (SHBCT, SEKCT, SEPACT, CCCT) now has its own validated request schema with the right field set, account types and patterns. The legacy API used one generic PaymentPayload for all products.
• creditorAccount.accountType is now strictly enumerated per product:
  • SHBCT — BBAN only (8–9 digit Swedish SHB account number)
  • SEKCT — BBAN, IBAN (Swedish IBANs only), PG, BG
  • SEPACT, CCCT Nordic, CCCT EU-payment — IBAN only
  • CCCT Normal / Express — IBAN or BBAN
• chargeBearer values are now tied to product:
  • SHAR — SEPACT, CCCT Nordic, CCCT EU-payment
  • CHAR, CRED, DEBT — CCCT Normal and Express
• PaymentTypeInformation uses ISO 20022 codes (SEPA, URGP, NURG) and category-purpose codes (SUPP, NOPA, EUSE).
• Stricter character patterns apply to creditor.name, remittanceInformation.text and similar fields — particularly for SHBCT, where remittance text is limited to 14 characters.

No, You must use the old endpoint (V1) to cancel and ask for status on payments.

• Developer Portal:https://developer.handelsbanken.com/api/
• Technical guidelines:https://developer.handelsbanken.com/api/psd2/guidelines/payments
• Sandbox info:https://developer.handelsbanken.com/api/sandbox/geninfo
• Country-specific (SE):https://developer.handelsbanken.com/api/apis/payments/se
• Go Live:https://developer.handelsbanken.com/api/psd2/live

Yes. There is no /payments/corporate/single/sek-credit-transfer endpoint. SEK credit transfers can be initiated only via POST /payments/corporate/signing-basket.

A basket containing a single payment is the correct and supported approach: the request requires the sekCreditTransfers array with minItems 1 (maxItems 100), so an array of length 1 is the intended way to initiate an individual cross-bank SEK transfer.

There is no basket-level status endpoint. Use the existing per-payment endpoint GET /payments/corporate/{paymentProduct}/{paymentId}/status with paymentProduct = sek-credit-transfer and the paymentId returned per payment in the initiation response.

The initiation response returns a payments array, each element carrying its own paymentId plus your tppPaymentReference; use that mapping to poll each payment.

The basket execute response returns only a basket-leveltransactionStatus (SUCCEEDED / FAILED / PARTIAL_FAILURE); it does not break results down per payment.

To identify individual outcomes, call the per-payment status endpoint for each paymentId. At payment level, transactionStatus uses ISO 20022 codes (ACTC, ACCP, ACSC, ACCC, PATC, CANC, RJCT). A failed payment shows RJCT, with reasonCode and reason giving the specific cause.

Recommended PARTIAL_FAILURE pattern

1. Execute basket. If transactionStatus = PARTIAL_FAILURE,
2. Iterate the payments array from the initiation response,
3. Call GET .../sek-credit-transfer/{paymentId}/status for each, treating RJCT + reasonCode/reason as the failure detail.