API docs by Redocly

OP Corporate Payment API (3.0.3)

Download OpenAPI specification:Download

Support: corp-payment-APIs@op.fi

*OP Corporate Payment API allows OP corporate customers to initiate payments from their accounts.

Authentication

Authentication in OP Corporate Payment API is based on practices from OpenID Connect (OIDC) 1.0 and OAuth 2.0. For further information on the token management and generation, please see OP Corporate Banking APIs Token management.

Payment request signature

To ensure that the payment request payload is not altered and evidence of non-repudiation is maintained, a signature is calculated over the payment request body. The signature is a detached content JWS, as defined in RFC7515 with the following mandatory JWS headers:

  • alg - string - only RS256 algorithm is currently supported for the signature algorithm
  • kid - string - The signature Key Identifier (KID) received from the registration UI, used to map the signing key to the correct public key at the verifying end.
  • b64 - boolean - The boolean value for this must be false. This indicates that the detached message payload is not base64 URL encoded when calculating the request signature. See RFC 7797 - The "b64" header Parameter
  • urn:op.api.iat - number - This must be a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in GMT until the date/time.
  • crit - array of string - This must be an array containing the critical header names, ["b64","urn:op.api.iat"]

The signature is computed in the detached mode, where the payload is not base64 URL encoded when forming the signature base string, but the UTF-8 encoded bytes of the sent request body are used as-is to construct the signature base string. See the example code below for more details.When sending the payment request, the signature must be included in the request header "X-Req-Signature", and it will be validated against the key matching the kid parameter.

Security Considerations

It is extremely important that the Client ID, Client Secret and mTLS certificate private key are not exposed at any point. Together they represent the identity of the client and thereby the corporation. In the possession of an attacker they could be used to make fraudulent API calls potentially causing considerable damage.

Sandbox

To test the API in sandbox environment, please send an email at corp-payment-APIs@op.fi. You will be granted a user ID and password to access OP API Admin in the sandbox environment.

Production access

You can get production access for this API on OP API Admin in production.

To use these APIs in production you should replace host in the API examples below with https://api.corporate-api.op.fi/

Change log

v3.0.3 (09/2026)

Changes

Endpoint status

v3.0.2 (2/2026)

  • Added clearingCode field to Cross-border Payment to support the use of clearing code in Cross-border Payments
  • Updated description for SEPA v3 Payment regarding Verification of Payee being available starting from fall 2025

v3.0.1 (10/2025)

#### Added
- Added more validation for `addressLine` array fields items in  [CreditorAddress](#schema/CreditorAddress), [DebtorAddress](#schema/DebtorAddress), [UltimateCreditorAddress](#schema/UltimateCreditorAddress) and [UltimateDebtorAddress](#schema/UltimateDebtorAddress)

v3.0.0 (04/2025)

Added

  • Added new endpoints SEPA V3 Payment and Payment V3 Status Query. The endpoints have new request and response fields related to the Verification of Payee service
  • Added vopProcessingRules field to SEPA V3 Payment to define allowed Verification of Payee (VOP) check results for payment processing
  • Added allowVopErrors field to SEPA V3 Payment to control payment processing behavior on Verification of Payee (VOP) technical errors
  • Added lei field in SEPA V3 Payment to support the use of Creditor Legal Entity Identifier
  • Added vopProcessingInfo field to Payment V3 Status Query response to provide detailed Verification of Payee (VOP) processing results

Deprecated

v2.0.2 (02/2025)

Deprecated

v2.0.0 (10/2024)

Added

  • Cross Border Payments APIs added

v1.6.5 (09/2024)

Changed

  • Changed link for OP Corporate Banking APIs Token Management

v1.6.4 (09/2024)

Changed

v1.6.3 (05/2024)

Added

  • Link to OP Corporate Banking APIs Token management (see Authentication section above)
  • Missing http error response codes and samples
  • Added missing parameter errorProcessingInfo and required parameter info to Payment V2 Status Query response

v1.6.2 (04/2024)

Changed

v1.6.1 (01/2024)

Added

  • Code examples added for all active endpoints

Changed

v1.6 (11/2023)

Added

  • New endpoint Payment V2 added in the sandbox environment. The endpoint allows for faster, asynchronous payment processing. Endpoints SEPA Payment and SEPA Instant Payment are not impacted by this new endpoint introduction
  • New endpoint Payment V2 Status Query added to support status queries for payments initiated with Payment V2 in the sandbox environment.
  • Code examples for calling POST endpoint on Payment V2. Please see the request samples section of the endpoint on the right select Code examples of desired language.

Changed

v1.5 (01/2023)

Added

  • Request parameter ultimateCreditor added to endpoints SEPA Payment and SEPA Instant Payment. Using this parameter, API users will be able to add information on the ultimate payee (ultimate creditor)

Changed

  • Request parameter endToEndId now allows for more special characters

v1.4 (09/2022)

Added

  • Request parameter ultimateDebtor added to endpoints SEPA Payment and SEPA Instant Payment. Using this parameter, API users will be able to add information on the ultimate payer (ultimate debtor)

v1.3 (04/2022)

Changed

v1.2 (12/2021)

Added

  • Corporate Payment API now supports OP Corporate Service Provider API usage

v1.1 (09/2021)

Changed

  • Improved the description for creditor and debtor address request parameters
  • Improved the way in which IBAN account numbers are handled

v1.0 (12/2019)Initial version

SEPA Payment V3

Initiates a SEPA payment asynchronously. Before payment processing a Verification of Payee (VOP) check is done, and only payments with allowed VOP result are processed.

Final status and other details for the payment should be fetched using the endpoint Payment V3 Status Query. Payments are initiated primarily as SEPA Instant payments. If the payment cannot be processed as a SEPA Instant payment, a SEPA payment is initiated. You can also initiate only SEPA Instant payments with parameter forceSepaInst. For code examples, please see 'Request samples' on the right.

header Parameters
authorization
required
string

Bearer JWT token

X-Req-Signature
required
string

Body signature

X-Request-ID
string

Unique identifier for a specific request. Used for debugging purposes

Request Body schema: application/json; charset=UTF-8
required

Payment info

allowVopErrors
required
boolean

Indicate if the payment is allowed for payment processing in case the Verification of Payee check ends up in a technical error.

When set to true, allows payment processing in case of a VOP error. When set to false, does not allow payment for processing in case of a VOP error.

required
object (CreditorV3)

Creditor for the payment

required
object (Debtor)

Debtor for the payment

required
object (InstructedAmount)
instructionId
required
string^[a-zA-Z0-9]{1,35}$

Unique identification, as assigned by the original instructing party for the original instructed party, to unambiguously identify the original instruction. The same value should be used to request payment status and cannot be used to make more than one payment.

vopProcessingRules
required
string
Enum: "MATCH" "CLOSE_MATCH" "NO_MATCH"

Indicate which Verification of Payee (VOP) check results are allowed for payment processing.

  • MATCH allows processing of payments with Match result, and when VOP check was not possible for the payee (NOT_POSSIBLE in Payment V3 Status Query).
  • CLOSE_MATCH allows processing of payments with Match and Close match results, and when VOP check was not possible for the payee (NOT_POSSIBLE in Payment V3 Status Query).
  • NO_MATCH allows processing of Match, Close match and No match results, and when VOP check was not possible for the payee (NOT_POSSIBLE in Payment V3 Status Query).

In case NO_MATCH is allowed, the payer should note that the amount might be transferred to unintended payee if the VOP result was a No match. In this case, the Bank is not liable for the damages.

endToEndId
string^[0-9A-Za-z-åäöÅÄÖ_=:.,+]{1,35}$

Unique identification, as assigned by the original initiating party, to unambiguously identify the original transaction.

forceSepaInst
boolean
Default: false

When set to true, forces the payment to be processed only as a SEPA Instant payment. When set to false, a SEPA payment may be initiated if the payment cannot be processed as a SEPA Instant payment.

message
string [ 1 .. 140 ] characters

Free form message from debtor to creditor. Either message or reference should be given to an outgoing payment.

reference
string [ 1 .. 25 ] characters

Structured creditor reference, either international RF reference (ISO 11649) or Finnish reference number (viitenumero). Either the reference or the message should be given for an outgoing payment.

object (UltimateCreditor)

Ultimate creditor for the payment

object (UltimateDebtor)

Ultimate debtor for the payment

Responses

Request samples

Content type
application/json; charset=UTF-8
{
  • "creditor": {
    },
  • "debtor": {
    },
  • "endToEndId": "544652-end2end",
  • "forceSepaInst": false,
  • "vopProcessingRules": "MATCH",
  • "allowVopErrors": false,
  • "instructedAmount": {
    },
  • "instructionId": "AtoZatoz01234567898NoLongerThan35",
  • "message": "Less money, fewer problems",
  • "reference": "482738",
  • "ultimateCreditor": {
    },
  • "ultimateDebtor": {
    }
}

Response samples

Content type
application/json; charset=UTF-8
{
  • "amount": "3.45",
  • "creditorIban": "FI4550009420999999",
  • "creditorName": "Cedric Creditor",
  • "currency": "EUR",
  • "debtorIban": "FI4550009420888888",
  • "endToEndId": "544652-end2end",
  • "forceSepaInst": false,
  • "vopProcessingRules": "MATCH",
  • "allowVopErrors": false,
  • "instructionId": "AtoZatoz01234567898NoLongerThan35",
  • "status": "PROCESSING",
  • "ultimateCreditorName": "Ultimate Creditor",
  • "ultimateDebtorName": "Ultimate Debtor"
}

SEPA Payment V3 Status Query

Get the VOP result and the status of a payment initiated with Payment V3.

path Parameters
instructionId
required
string

instructionId used when the payment was initiated

header Parameters
authorization
required
string

Bearer JWT token

X-Request-ID
string

Unique identifier for a specific request. Used for debugging purposes

Responses

Request samples 

## OP Corporate Payment API - SEPA Payment V3 Status Query bash script example

#!/bin/bash

# To run this script you need openssl and jq installed.

# Steps for registering the required keys and certificates
# 1. Valid Corporate API contract created in OP API Admin
# 2. OAuth clientId and clientSecret provisioned
# 3. MTLS private key generated: openssl genrsa -out sandbox-mtls.key 4096
# 4. MTLS certificate signing request (CN and other attributes are ignored): openssl req -new -key sandbox-mtls.key -out sandbox-mtls.csr
# 5. Valid MTLS certificate downloaded from OP API Admin as file "sandbox-mtls.crt" by uploading the certificate signing request (CSR) from the previous step
# 6. Payment signing private key generated: openssl genrsa -out sandbox-signing.key 4096
# 7. Signing csr request: openssl req -new -key sandbox-signing.key -out sandbox-signing.csr
# 8. Signing KID (key identifier) received from the OP API Admin by submitting the sandbox-signing.csr.

# OAuth credentials
clientId="TODO put here oauth client id"
clientSecret="TODO and here client secret"

# MTLS credentials
mtlsKey="sandbox-mtls.key"
mtlsCertificate="sandbox-mtls.crt"

# Payment signing credentials
signingKey="sandbox-signing.key"
signingKid="TODO and here signing KID"

API_SERVER="https://api.sandbox.corporate-api.op.fi"

echo "Getting access token"
reply=$(curl -s ${API_SERVER}/corporate-oidc/v1/token \
    --key ${mtlsKey} \
    --cert ${mtlsCertificate} \
    -H 'Content-Type: application/x-www-form-urlencoded' \
    -d "grant_type=client_credentials&client_id=${clientId}&client_secret=${clientSecret}")

token=$(echo $reply | jq -r .access_token)
echo "Access token is: $token"\

## Initiate payment processing with payload signature# Instruction id must be unique for each payment request
INSTRUCTIONID=$(date +%s)
DEBTORIBAN="TODO Your account IBAN from the API contract"
CREDITORIBAN="TODO Your account IBAN from the API contract"

# Sample payment request with dummy data
paymentRequest="{\"instructionId\":\"$INSTRUCTIONID\",\"endToEndId\":\"endToEndId\",\"vopProcessingRules\":\"MATCH\",\"allowVopErrors\":false,\"creditor\":{\"name\":\"Creditor Name\",\"iban\":\"$CREDITORIBAN\",\"address\":{\"addressLine\":[\"a1\",\"a2\"],\"country\":\"FI\"}},\"debtor\":{\"name\":\"Debtor Name\",\"iban\":\"$DEBTORIBAN\",\"address\":{\"addressLine\":[\"a1\",\"a2\"],\"country\":\"FI\"}},\"instructedAmount\":{\"currency\":\"EUR\",\"amount\":\"0.16\"},\"reference\":\"00000000000000482738\"}"

## Signing the payload is mandatory for payment requests
# Issued at, in unix timestamp format
IAT=$(date +%s)

# Form the JWS header with mandatory fields
HEADER="{\"b64\":false,\"crit\":[\"b64\",\"urn:op.api.iat\"],\"alg\":\"RS256\",\"urn:op.api.iat\":${IAT},\"kid\":\"${signingKid}\"}"

# Base64 encode the header. JWT encoding is slightly different from default
# output of base64, so make the necessary changes to make the output URL-safe,
# and remove trailing padding (=).
HEADER_ENC=$(echo -n "${HEADER}" | base64 | tr -- '+/=' '-_ ' | tr -d '[:space:]')

# Sign the header and payload. The signature calculation in the detached body JWS is slightly different from the standard way, as the payload is not base64-encoded
# before signing, but included as-is in the signature plain text. The signing algorithm is RS256, also known as "RSA Digital Signature Algorithm with SHA-256".# The resulting signature is base64-encoded, and the same URL-safe transformations are applied.
SIGNATURE=$(echo -n "${HEADER_ENC}.${paymentRequest}" | openssl dgst -sha256 -sign ${signingKey} -binary | openssl base64 -e -A | tr -- '+/=' '-_ ' | tr -d '[:space:]')

# The signature header includes the base64-encoded JWS header, followed by two dots (..), and the base64-urlsafe-encoded signature. The actual message payload is not
# repeated in the signature
REQ_SIGNATURE="${HEADER_ENC}..${SIGNATURE}"

# The signature is included in the "X-Req-Signature" header.
echo "Sending payment request"
paymentResponse=$(curl -s ${API_SERVER}/corporate-payment/v3/payment \
    --key ${mtlsKey} \
    --cert ${mtlsCertificate} \
    -H 'Content-Type: application/json' \
    -H "Authorization: Bearer $token" \
    -H "X-Req-Signature: ${REQ_SIGNATURE}" \
    -d "$paymentRequest")
echo $paymentResponse | jq -C .

echo "Sending payment status query request"
paymentStatusQueryResponse=$(curl -X GET ${API_SERVER}/corporate-payment/v3/payment/$INSTRUCTIONID \
    --key ${mtlsKey} \
    --cert ${mtlsCertificate} \
    -H 'Accept: application/json' \
    -H "Authorization: Bearer $token")
echo $paymentStatusQueryResponse | jq -C .

Response samples

Content type
application/json; charset=UTF-8
Example
{
  • "amount": 1.23,
  • "bookingDate": "2019-05-11",
  • "currency": "EUR",
  • "creditorName": "Creditor Name",
  • "creditorIban": "FI4550009420888888",
  • "ultimateCreditorName": "Ultimate Creditor",
  • "debtorIban": "FI4550009420999999",
  • "ultimateDebtorName": "Ultimate Debtor",
  • "transactionDate": "2019-05-11",
  • "paymentType": "SCT_INST",
  • "status": "PROCESSED",
  • "endToEndId": "544652-end2end",
  • "instructionId": "AtoZatoz01234567898NoLongerThan35",
  • "vopProcessingInfo": {
    }
}

Cross-border Payment

Initiates a cross-border payment. A cross-border payment means a payment for a creditor outside SEPA area or to a non-SEPA creditor bank and/or a payment in other currencies than Euro. Service charges of outgoing cross-border payments applies to the transaction executed. Charges can be managed with parameter charges. Payments are executed as normal payment orders, and the applicable instructions and cut-off times can be found on op.fi.

Final status and other details for the payment can be retrieved using the endpoint Cross-border Payment Status Query . If the payment was executed as a GPI payment further payment status and details after OP processing can be tracked using OP Corporate International Payment Tracking API.

For code examples, please use the examples on SEPA Payment V3 as a reference.

Cross-border payments are only available during extended business hours. Outside the operating hours an error response is sent.

header Parameters
authorization
required
string

Bearer JWT token

X-Req-Signature
required
string

Body signature

X-Request-ID
string

Unique identifier for a specific request. Used for debugging purposes

Request Body schema: application/json; charset=UTF-8
required

Payment info

required
object (CBCreditor)

Creditor for the payment

required
object or object (CreditorAgent)

Creditor agent for the payment. Exactly one of bic or clearingCode must be provided.

required
object (CBDebtor)
required
object (InstructedAmountCb)
instructionId
required
string^[a-zA-Z0-9]{1,35}$

Unique identification, as assigned by the original instructing party for the original instructed party, to unambiguously identify the original instruction. The same value should be used to request payment status and cannot be used to make more than one payment.

message
required
string [ 1 .. 140 ] characters

Free form message from debtor to creditor.

categoryPurposeCode
string
Enum: "CORT" "INTC"

Category purpose code. Available codes:

  • CORT - Corporate Trade. Payment is made in settlement of a trade (e.g. foreign exchange deal, securities transaction)
  • INTC - Intra-Company Payment. A payment between two companies belonging to the same group
charges
string
Enum: "SHA" "OUR"

How charges related to processing of this payment are managed. On ETA-area payments, only the (default) shared charges model is allowed. Charge codes:

  • SHA - Shared transfer charges, the default mode
  • OUR - Payer (debtor) pays all the charges
endToEndId
string^[0-9A-Za-z-åäöÅÄÖ_=:.,+]{1,35}$

Unique identification, as assigned by the original initiating party, to unambiguously identify the original transaction.

object (UltimateCreditor)

Ultimate creditor for the payment

object (UltimateDebtor)

Ultimate debtor for the payment

Responses

Request samples

Content type
application/json; charset=UTF-8
{
  • "categoryPurposeCode": "CORT",
  • "charges": "SHA",
  • "creditor": {
    },
  • "creditorAgent": {
    },
  • "debtor": {
    },
  • "endToEndId": "544652-end2end",
  • "instructedAmount": {
    },
  • "instructionId": "AtoZatoz01234567898NoLongerThan35",
  • "message": "Less money, fewer problems",
  • "ultimateCreditor": {
    },
  • "ultimateDebtor": {
    }
}

Response samples

Content type
application/json; charset=UTF-8
{
  • "amount": "3.45",
  • "charges": "SHA",
  • "creditorAgentBic": "DEUTDEDE",
  • "creditorAccount": "FI4550009420999999",
  • "creditorName": "Cedric Creditor",
  • "currency": "EUR",
  • "debtorIban": "FI4550009420888888",
  • "debtorName": "Debtor Name",
  • "endToEndId": "544652-end2end",
  • "instructionId": "AtoZatoz01234567898NoLongerThan35",
  • "message": "Less money, fewer problems",
  • "status": "PROCESSING",
  • "ultimateCreditorName": "Ultimate Creditor",
  • "ultimateDebtorName": "Ultimate Debtor"
}

Cross-border Payment Status Query

Get the status of a cross-border payment initiated with Cross-border Payment.

path Parameters
instructionId
required
string

instructionId used when the payment was initiated

header Parameters
authorization
required
string

Bearer JWT token

X-Request-ID
string

Unique identifier for a specific request. Used for debugging purposes

Responses

Request samples 

curl -X GET https://api.sandbox.corporate-api.op.fi/corporate-payment/v2/cross-border-payment/{instructionId} \
-H 'authorization: string' \
-H 'X-Request-ID: string' \
-H 'Accept: application/json' \
-H 'Content-Type: application/json'

Response samples

Content type
application/json; charset=UTF-8
{
  • "amount": "3.45",
  • "archiveId": "20190524593156999999",
  • "bookingDate": "2019-05-12",
  • "categoryPurposeCode": "CORT",
  • "charges": "SHA",
  • "creditorAgent": {
    },
  • "creditorAccount": "FI4550009420999999",
  • "creditorName": "Cedric Creditor",
  • "currency": "EUR",
  • "debtorIban": "FI4550009420888888",
  • "endToEndId": "544652-end2end",
  • "errorProcessingInfo": {
    },
  • "instructionId": "AtoZatoz01234567898NoLongerThan35",
  • "paymentType": "CROSS-BORDER_PAYMENT",
  • "status": "PROCESSED",
  • "transactionDate": "2019-05-11",
  • "ultimateCreditorName": "Ultimate Creditor",
  • "ultimateDebtorName": "Ultimate Debtor"
}

SEPA Payment V4 [Draft]

This draft endpoint provides an example of the address fields that will be introduced as part of the future ISO 20022 address requirements update. Endpoint is currently not available in Sandbox or Production and should not be used.

More detailed information and rollout schedule will be provided once the new endpoints and ISO 20022 compliant address fields become available.

header Parameters
authorization
required
string

Bearer JWT token

X-Req-Signature
required
string

Body signature

X-Request-ID
string

Unique identifier for a specific request. Used for debugging purposes

Request Body schema: application/json; charset=UTF-8
required

Payment info

allowVopErrors
required
boolean

Indicate if the payment is allowed for payment processing in case the Verification of Payee check ends up in a technical error.

When set to true, allows payment processing in case of a VOP error. When set to false, does not allow payment for processing in case of a VOP error.

required
object (CreditorV4)

Creditor for the payment

required
object (DebtorV4)

Debtor for the payment

required
object (InstructedAmount)
instructionId
required
string^[a-zA-Z0-9]{1,35}$

Unique identification, as assigned by the original instructing party for the original instructed party, to unambiguously identify the original instruction. The same value should be used to request payment status and cannot be used to make more than one payment.

vopProcessingRules
required
string
Enum: "MATCH" "CLOSE_MATCH" "NO_MATCH"

Indicate which Verification of Payee (VOP) check results are allowed for payment processing.

  • MATCH allows processing of payments with Match result, and when VOP check was not possible for the payee (NOT_POSSIBLE in Payment V3 Status Query).
  • CLOSE_MATCH allows processing of payments with Match and Close match results, and when VOP check was not possible for the payee (NOT_POSSIBLE in Payment V3 Status Query).
  • NO_MATCH allows processing of Match, Close match and No match results, and when VOP check was not possible for the payee (NOT_POSSIBLE in Payment V3 Status Query).

In case NO_MATCH is allowed, the payer should note that the amount might be transferred to unintended payee if the VOP result was a No match. In this case, the Bank is not liable for the damages.

endToEndId
string^[0-9A-Za-z-åäöÅÄÖ_=:.,+]{1,35}$

Unique identification, as assigned by the original initiating party, to unambiguously identify the original transaction.

forceSepaInst
boolean
Default: false

When set to true, forces the payment to be processed only as a SEPA Instant payment. When set to false, a SEPA payment may be initiated if the payment cannot be processed as a SEPA Instant payment.

message
string [ 1 .. 140 ] characters

Free form message from debtor to creditor. Either message or reference should be given to an outgoing payment.

reference
string [ 1 .. 25 ] characters

Structured creditor reference, either international RF reference (ISO 11649) or Finnish reference number (viitenumero). Either the reference or the message should be given for an outgoing payment.

object (UltimateCreditorV4)

Ultimate creditor for the payment

object (UltimateDebtorV4)

Ultimate debtor for the payment

Responses

Request samples

Content type
application/json; charset=UTF-8
{
  • "creditor": {
    },
  • "debtor": {
    },
  • "endToEndId": "544652-end2end",
  • "forceSepaInst": false,
  • "vopProcessingRules": "MATCH",
  • "allowVopErrors": false,
  • "instructedAmount": {
    },
  • "instructionId": "AtoZatoz01234567898NoLongerThan35",
  • "message": "Less money, fewer problems",
  • "reference": "482738",
  • "ultimateCreditor": {
    },
  • "ultimateDebtor": {
    }
}

Response samples

Content type
application/json; charset=UTF-8
{
  • "amount": "3.45",
  • "creditorIban": "FI4550009420999999",
  • "creditorName": "Cedric Creditor",
  • "currency": "EUR",
  • "debtorIban": "FI4550009420888888",
  • "endToEndId": "544652-end2end",
  • "forceSepaInst": false,
  • "vopProcessingRules": "MATCH",
  • "allowVopErrors": false,
  • "instructionId": "AtoZatoz01234567898NoLongerThan35",
  • "status": "PROCESSING",
  • "ultimateCreditorName": "Ultimate Creditor",
  • "ultimateDebtorName": "Ultimate Debtor"
}

SEPA Payment V4 Status Query [Draft]

This draft endpoint provides an example of the address fields that will be introduced as part of the future ISO 20022 address requirements update. Endpoint is currently not available in Sandbox or Production and should not be used.

More detailed information and rollout schedule will be provided once the new endpoints and ISO 20022 compliant address fields become available.

path Parameters
instructionId
required
string

instructionId used when the payment was initiated

header Parameters
authorization
required
string

Bearer JWT token

X-Request-ID
string

Unique identifier for a specific request. Used for debugging purposes

Responses

Request samples 

curl -X GET https://api.sandbox.corporate-api.op.fi/corporate-payment/v4/payment/{instructionId} \
-H 'authorization: string' \
-H 'X-Request-ID: string' \
-H 'Accept: application/json' \
-H 'Content-Type: application/json'

Response samples

Content type
application/json; charset=UTF-8
Example
{
  • "amount": 1.23,
  • "bookingDate": "2019-05-11",
  • "currency": "EUR",
  • "creditorName": "Creditor Name",
  • "creditorIban": "FI4550009420888888",
  • "ultimateCreditorName": "Ultimate Creditor",
  • "debtorIban": "FI4550009420999999",
  • "ultimateDebtorName": "Ultimate Debtor",
  • "transactionDate": "2019-05-11",
  • "paymentType": "SCT_INST",
  • "status": "PROCESSED",
  • "endToEndId": "544652-end2end",
  • "instructionId": "AtoZatoz01234567898NoLongerThan35",
  • "vopProcessingInfo": {
    }
}

Cross-border Payment V3 [Draft]

This draft endpoint provides an example of the address fields that will be introduced as part of the future ISO 20022 address requirements update. Endpoint is currently not available in Sandbox or Production and should not be used.

More detailed information and rollout schedule will be provided once the new endpoints and ISO 20022 compliant address fields become available.

header Parameters
authorization
required
string

Bearer JWT token

X-Req-Signature
required
string

Body signature

X-Request-ID
string

Unique identifier for a specific request. Used for debugging purposes

Request Body schema: application/json; charset=UTF-8
required

Payment info

required
object (CBCreditorV3)

Creditor for the payment

required
object or object (CreditorAgentV3)

Creditor agent for the payment. Exactly one of bic or clearingCode must be provided.

required
object (CBDebtorV3)
required
object (InstructedAmountCb)
instructionId
required
string^[a-zA-Z0-9]{1,35}$

Unique identification, as assigned by the original instructing party for the original instructed party, to unambiguously identify the original instruction. The same value should be used to request payment status and cannot be used to make more than one payment.

message
required
string [ 1 .. 140 ] characters

Free form message from debtor to creditor.

categoryPurposeCode
string
Enum: "CORT" "INTC"

Category purpose code. Available codes:

  • CORT - Corporate Trade. Payment is made in settlement of a trade (e.g. foreign exchange deal, securities transaction)
  • INTC - Intra-Company Payment. A payment between two companies belonging to the same group
charges
string
Enum: "SHA" "OUR"

How charges related to processing of this payment are managed. On ETA-area payments, only the (default) shared charges model is allowed. Charge codes:

  • SHA - Shared transfer charges, the default mode
  • OUR - Payer (debtor) pays all the charges
endToEndId
string^[0-9A-Za-z-åäöÅÄÖ_=:.,+]{1,35}$

Unique identification, as assigned by the original initiating party, to unambiguously identify the original transaction.

object (UltimateCreditorCBV3)

Ultimate creditor for the payment

object (UltimateDebtorCBV3)

Ultimate debtor for the payment

Responses

Request samples

Content type
application/json; charset=UTF-8
{
  • "categoryPurposeCode": "CORT",
  • "charges": "SHA",
  • "creditor": {
    },
  • "creditorAgent": {
    },
  • "debtor": {
    },
  • "endToEndId": "544652-end2end",
  • "instructedAmount": {
    },
  • "instructionId": "AtoZatoz01234567898NoLongerThan35",
  • "message": "Less money, fewer problems",
  • "ultimateCreditor": {
    },
  • "ultimateDebtor": {
    }
}

Response samples

Content type
application/json; charset=UTF-8
{
  • "amount": "3.45",
  • "charges": "SHA",
  • "creditorAgentBic": "DEUTDEDE",
  • "creditorAccount": "FI4550009420999999",
  • "creditorName": "Cedric Creditor",
  • "currency": "EUR",
  • "debtorIban": "FI4550009420888888",
  • "debtorName": "Debtor Name",
  • "endToEndId": "544652-end2end",
  • "instructionId": "AtoZatoz01234567898NoLongerThan35",
  • "message": "Less money, fewer problems",
  • "status": "PROCESSING",
  • "ultimateCreditorName": "Ultimate Creditor",
  • "ultimateDebtorName": "Ultimate Debtor"
}

Cross-border Payment V3 Status Query [Draft]

This draft endpoint provides an example of the address fields that will be introduced as part of the future ISO 20022 address requirements update. Endpoint is currently not available in Sandbox or Production and should not be used.

More detailed information and rollout schedule will be provided once the new endpoints and ISO 20022 compliant address fields become available.

path Parameters
instructionId
required
string

instructionId used when the payment was initiated

header Parameters
authorization
required
string

Bearer JWT token

X-Request-ID
string

Unique identifier for a specific request. Used for debugging purposes

Responses

Request samples 

curl -X GET https://api.sandbox.corporate-api.op.fi/corporate-payment/v3/cross-border-payment/{instructionId} \
-H 'authorization: string' \
-H 'X-Request-ID: string' \
-H 'Accept: application/json' \
-H 'Content-Type: application/json'

Response samples

Content type
application/json; charset=UTF-8
{
  • "amount": "3.45",
  • "archiveId": "20190524593156999999",
  • "bookingDate": "2019-05-12",
  • "categoryPurposeCode": "CORT",
  • "charges": "SHA",
  • "creditorAgent": {
    },
  • "creditorAccount": "FI4550009420999999",
  • "creditorName": "Cedric Creditor",
  • "currency": "EUR",
  • "debtorIban": "FI4550009420888888",
  • "endToEndId": "544652-end2end",
  • "errorProcessingInfo": {
    },
  • "instructionId": "AtoZatoz01234567898NoLongerThan35",
  • "paymentType": "CROSS-BORDER_PAYMENT",
  • "status": "PROCESSED",
  • "transactionDate": "2019-05-11",
  • "ultimateCreditorName": "Ultimate Creditor",
  • "ultimateDebtorName": "Ultimate Debtor"
}