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.

Handelsbanken Domestic Credit Transfer is for Handelsbanken accounts only

The payment product handelsbanken-domestic-credit-transfer (SHBCT) can only be used to credit accounts held at Handelsbanken. It cannot be used to pay an account at another Swedish bank.

This restriction is enforced by the schema. A request that targets an account at another bank will be rejected with an HTTP 400, typically referencing creditorAgent.identification.code and creditorAccount.value.

If the destination clearing number falls outside 6000–6999, the account is not a Handelsbanken account and this product is not the correct one to use.

Paying an account at another Swedish bank

To send a domestic SEK payment to an account held at another Swedish bank, use the SEK Credit Transfer product (sek-credit-transfer, SEKCT) instead. SEKCT accepts accountType values IBAN, BBAN, PG and BG, so you can pass a Swedish IBAN directly without splitting out the clearing number.

Note that SEKCT is available only through a signing basket. There is no single-payment endpoint for this product.

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.

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.

When you initiate a basket payment (for example SEKCT, which is basket-only), the response gives you two different kinds of identifier. Using the wrong one in the signing and execution steps is the single most common cause of authorization failures we see during migration. This article explains which ID to use, where, and why.

The two identifiers you receive

A successful call to POST /payments/private/signing-basket (or /payments/corporate/signing-basket) returns a 201 containing:

1. One signingBasketId — the identifier for the basket as a whole.
2. A payments array, where each individual payment in the basket has its own paymentId and tppPaymentReference.

In other words, the response looks like this in shape: { "signingBasketId": "...", "payments": [ { "paymentId": "...", "tppPaymentReference": "..." } ] }

Both IDs are valid and both have a purpose — but they are not interchangeable.

The rule

For a basket payment, the SCA authorisation, the token exchange, and the execution call must all reference the signingBasketId. The paymentId values identify the individual payments inside the basket; they are never used to drive signing or execution of the basket.

Where each step uses the basket ID

1. Initiate the basket. Call POST /payments/private/signing-basket. Read the signingBasketId from the response and keep it.
2. Start SCA. Build the authorisation request that redirects the PSU so that it is bound to the signingBasketId. The consent the PSU gives is for the basket, not for one payment within it.
3. Exchange the code for a token. The access token you obtain after the redirect is bound to that same signingBasketId. Do not start a new authorisation against a paymentId at this point.
4. Execute the basket. Call PUT /payments/private/signing-basket/{signingBasketId}, using the same signingBasketId as the path parameter and the token from step 3.

The same four steps apply to the Corporate API using the /payments/corporate/signing-basket paths.

The pitfall: what happens if you use a paymentId instead

If you pick one of the paymentId values out of the payments array and use it to drive SCA or the token exchange, the identifier you authorise will not match the resource you are trying to execute. The typical symptoms are:

1. A 401 or 403 at the authorisation or token step, because the token is not valid for the resource being addressed.
2. A PUT to the basket that fails because the token was bound to a payment, not to the basket.
3. Intermittent success in test and failure in production, when the IDs happen to be cross-wired only some of the time.

These errors are raised before any payment processing takes place, so retrying the payment payload will not help. The fix is always to align the identifier: use the signingBasketId consistently from the authorisation redirect through to the PUT execution.

Quick checklist before you go live

1. Am I storing the signingBasketId from the initiation response, and not a paymentId?
2. Is my authorisation redirect bound to the signingBasketId?
3. Is the access token I use for execution the one obtained for that signingBasketId?
4. Does my PUT path read /signing-basket/{signingBasketId} with the same value?

If all four answer yes, the identifier chain is consistent and the basket will sign and execute correctly.

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.

A SEK credit transfer is a payment to an account held with Handelsbanken (SHB) or another bank on the Swedish market. Approved payments are processed through Swedish (SE) clearing on the same day.

Cut-off times

Cut-off times apply on business days and are stated in CET. From 4 May, the cut-off times are 03:45, 07:45, 08:45, 09:45, 10:45, 11:45 and 12:45. From 15 May, the cut-off times are extended to also include 13:45 and 14:45.

New attempts (retry logic)

If a payment cannot be settled at the first attempt, further attempts are made automatically. The rules differ between private and corporate payers.

1. Individuals: New attempts are made during the payment date, prior to the cut-off times, and on the following two banking days. If the payment is still unsuccessful, it is permanently stopped due to lack of funds.
2. Corporate: New attempts are made during the payment date, prior to the cut-off times. If the payment is still unsuccessful, it is permanently stopped after the last clearing cycle.

• 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