With the Business Payment Initiation APIs, you can initiate Single credit transfers or Bulk payment files on behalf of your users with a Rabobank business payment account and retrieve the status of an initiated transaction or file.

Business Payment Initiation is a part of Rabo BoekhoudKoppeling and Rabo Banking Link. This API supports all third parties and direct customers.

Business Payment Initiation consists of two separate APIs:

• Business Single Payment Initiation
• Business Bulk Payment Initiation

This API allows you or your clients (with a Rabobank business account) to process single or bulk payments through your application.

To know more read the manual that connects to your use case:

• Read Rabo Banking Link for third parties
• Read Rabo Banking Link manual for direct connectors

These APIs can be used through your app or web service to optimize your customer journey. It is suited for Euro Payments (SEPA), World Payments (non-SEPA), and transfers between your own (savings) accounts. After initiating a payment, you can also request its status.

🚧

To authorize single payment orders initiated using Business Payment Initiation, it depends on the redirectionFlag in the POST request whether the account holder must use Rabo Business Banking or Rabo Business Banking Pro or they can sign directly from your platform, using the redirect URL that you received from us.

To authorize batch payment orders initiated using Business Payment Initiation, the account holder must use Rabo Business Banking or Rabo Business Banking Pro.

IBAN Name Check

With the IBAN name check you enable your software users to check their customer and/or supplier data. This way the user can verify the account name associated with the payment.

You can easily add the IBAN Name Check to your customer journey using Rabobank Identity Services

Next steps

To enable you to further optimise your customer journey, we are working on the following:

• The ability to let account holders sign payment batches directly from your own platform using a redirect to the Rabobank signing screens.
• Push status information for a better API user experience.

We will keep you updated on the progress.

Relevant scope(s) for oauth2 access code flow

📘

Make sure that you use the Authorization and Token URL as provided by the Authorization Services.

Rate Limiting

A default rate limit plan is set for all APIs. The rate limit can be shared or individual (defined per operation). The table below describes the rate limiting for this product.

Business Single Payment Initiation

Before initiating single payments, the account holder must provide consent to the third party for sending single payment orders to Rabobank on behalf of their organisation for the specified payment account(s). This consent is continuous.

1. The account holder initiates the payment order to be executed by Rabobank using your platform.
2. Rabobank provides the API user (third party) with the status on the submitted upload.
3. The customer authorizes the payment:
   • in Rabo Business Banking or Rabo Business Banking Pro using Sign/Sign orders from the menu, or
   • directly from your platform, using the redirect URL that you received from us (optional, on request) after submitting the payment order.
4. After successful authorisation, Rabobank starts processing the payment order following its payment process same as if the payment is submitted using a Rabobank channel. This means (among others):
   • If a payment order is refused due to insufficient funds, we may check one or more times, up to and including three working days after the date of refusal, whether the reason for refusal still exists. If we believe that there is no longer a reason for refusal, we may restart processing the payment order on behalf of our customer.
   • When processing a Euro Payment, we check whether the beneficiary's bank is reachable for Instant Payments. If true, we will process the payment order as an Instant Payment. If false, we will process the payment order as a normal SEPA Credit Transfer.
5. The third party can retrieve the status of the payment through the status endpoint to keep track.

Requests

The POST Payment and GET Status requests must contain a digital signature. You can generate this digital signature using the private key of your certificate. For the Sandbox environment, you can use an example certificate available in the Signing documentation.

You can initiate a payment with POST /v1/single/sepa-credit-transfers

POST https://api-sandbox.rabobank.nl/openapi/sandbox/payments/v1/single/sepa-credit-transfers

To view full list of POST parameters, go to:

• POST/v1/single/cross-border-credit-transfers
• POST/v1/single/sepa-credit-transfers
• POST/v1/periodic/cross-border-credit-transfers
• POST/v1/periodic/sepa-credit-transfers

You can retrieve the details of a payment with GET /v1/single/sepa-credit-transfers/{paymentId}

GET https://api-sandbox.rabobank.nl/openapi/sandbox/payments/v1/single/sepa-credit-transfers/123e4567-e89b-42d3-a456-556642440005

You can retrieve the status of a payment with GET /v1/single/cross-border-credit-transfers/{paymentId}/status

GET https://api-sandbox.rabobank.nl/openapi/sandbox/payments/v1/single/cross-border-credit-transfers/123e4567-e89b-42d3-a456-556642440005/status

Transfer between Payment accounts and Piggy banks

For single and periodic SEPA credit transfers, you are able to transfer money between payment accounts and piggy banks using the following:

• From IBAN payment account to IBAN savings account: add Amount and enter naar: piggy bank name in the unstructured remittance information.
• From IBAN savings account to IBAN payment account: add Amount and enter van: piggy bank name in the unstructured remittance information.

🚧

Money transfer from a piggy bank to an IBAN payment account is allowed only when both accounts are within the same agreement.

In case the piggy bank name is not spelled correctly, then the amount is transferred to the GENERAL piggy bank of the savings account.

To retrieve the balance information on piggy banks, use the BAI Balances API.

Response

POST Payment for Business Payment Initiation Single Payments

You can initiate a Single Business payment using a POST payments request.

After receiving the payment, a response of PDNG or RJCT is returned. You can use the {paymentId} endpoint to get the details of the payment and the status endpoint to get the latest status of the payment.

To view the POST parameters, read the following endpoint descriptions:

• POST/v1/single/cross-border-credit-transfers
• POST/v1/single/sepa-credit-transfers
• POST/v1/periodic/cross-border-credit-transfers
• POST/v1/periodic/sepa-credit-transfers

Example (POST /v1/payments/sepa-credit-transfers):

{
  "paymentId": "123e4567-e89b-42d3-a456-456789345678",
  "transactionStatus": "PDNG"
}

Below you can find all supported test scenarios. In order to test these scenarios, call the API by using the examples for the fields provided in the endpoint description for POST/sepa-credit-transfers.

Supported Scenarios

Note: These codes are for Sandbox only.

To create a recurring payment, you need to use the API contains periodic with the following extra content.

The difference between single SEPA credit transfer and recurring payment is the startDate and frequency are mandatory. The rest of the scenarios are the same as single SEPA credit transfers.

GET Payment details for Business Payment Initiation Single Payments

You can retrieve the detail information for a payment initiation using a GET {paymentId} request.

Some scenarios, as mentioned below, require specific paymentId(s) in the URL, example: (GET /v1/single/sepa-credit-transfers/{paymentId}) to get the mentioned responses.

To view the GET parameters, read the following endpoint description:

• GET /v1/single/sepa-credit-transfers/{paymentId}
• GET /v1/periodic/sepa-credit-transfers/{paymentId}
• GET /v1/single/cross-border-credit-transfers/{paymentId}
• GET /v1/periodic/cross-border-credit-transfers/{paymentId}

Example (/v1/payments/sepa-credit-transfers/{paymentId}):

{
    "creditorAccount": {
        "iban": "NL10RABO0123456789"
    },
    "creditorName": "Company",
    "debtorAccount": {
        "currency": "EUR",
        "iban": "NL10RABO0912345678"
    },
    "debtorName": "Mason Stevens",
    "instructedAmount": {
        "content": "10.25"
    }
}

Below you can find all supported test scenarios:

Note: These codes are for Sandbox only, for testing with the Sandbox example values for Signature add header Date = Tue, 24 Jan 2023 06:53:05 GMT

GET Payment Status for Business Payment Initiation Single Payments

You can retrieve the status information for a payment initiation using a GET status request.

Some scenarios, as mentioned below, require specific paymentId(s) in the URL, example: GET v1/single/sepa-credit-transfers/{paymentId}/status to get the mentioned responses.

To view the GET parameters, read the following endpoint description:

• GET /v1/single/sepa-credit-transfers/{paymentId}/status
• GET /v1/periodic/sepa-credit-transfers/{paymentId}/status
• GET /v1/single/cross-border-credit-transfers/{paymentId}/status
• GET /v1/periodic/cross-border-credit-transfers/{paymentId}/status

Example

{
    "transactionStatus": "PDNG"
}

Below you can find all supported test scenarios:

Note: These codes are for Sandbox only.

Here is a description of the expected response statuses:

Business Bulk Payment Initiation

The POST payment and GET status requests must contain a digital signature. You can generate this digital signature using the private key of your certificate. For the Sandbox environment, you can use an example certificate available in the Signing documentation.

The POST call requires a PAIN001 file, read more about it here.

Before sending payment order files, the account holder must provide consent to the third party for sending payment files to Rabobank on behalf of their organisation for the specified payment account(s). This consent is continuous.

1. The API user (third party) sends the payment order file(s) containing batches with payment orders using the Business Bulk Payment Initiation API.

   🚧

   For some countries, special rules apply for World Payments. Read more information about countries here: Betalingsinformatie per land

2. Rabobank provides the third party with the status on the submitted bulk upload.

3. The customer authorises the payment batches in Rabo Business Banking or Rabo Business Banking Pro using Sign/Sign Orders from the menu.

4. After successful authorisation, Rabobank processes the payment batches following their payment process, same as if the payment is submitted using a Rabobank channel.

5. The API user (third party) can retrieve the status of the individual payments in the batches through PAIN-002.

🚧

Payment files with multiple batches can be sent to the bank using BBPI with a maximum of 3,000 batches contained in one payment file at a time. It is also advisable to put a maximum of 25,000 payment orders in one payment file to ensure smooth processing. Larger files with more than 25,000 payment orders can best be split into multiple files.

Requests

The POST Payment and GET Status requests must contain a digital signature. You can generate this digital signature using the private key of your certificate. For the Sandbox environment, you can use an example certificate available in the Signing documentation.

The POST call requires a PAIN001 file, read more about it here.

To view full list of GET and POST parameters, go to:

• GET/credit-transfers/{paymentId}/status
• POST/credit-transfers

📘

You can only use business current accounts as Ordering account/Debtor Account.

Response

POST Payment initiation for Business Bulk Payment Initiation.

You can initiate a bulk credit transfer payment using a POST payment request.

After receiving the payment, a response of RCVD or RJCT is returned. You can use the status endpoint to get the latest status of the payment.

  `    {
      <?xml version="1.0" encoding="UTF-8"?>
      <InitiatedTransactionResponse>
          <_links>
             <status>
                 <href>/payments/bulk/credit-transfers/123e4567-e89b-42d3-a456-556642440001/status</href>
             </status>
          </_links>
          <paymentId>123e4567-e89b-42d3-a456-556642440001</paymentId>
          <transactionStatus>RCVD</transactionStatus>
      </InitiatedTransactionResponse>
    }
   `

If a required header is not provided or blank, then the status of the response will be 400 BAD REQUEST and the response will contain the missing header name. For example if the header Signature is missing, then the response will be:

`       <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
       <ErrorResponse>
         <errorMessages>
           <category>WARNING</category>
           <code>FORMAT_ERROR</code>
           <text>Required header 'signature' is not present</text>
         </errorMessages>
       </ErrorResponse>
      `  

Below you can find all supported test scenarios. In order to test these scenarios, call the API by using the examples for the fields provided in the endpoint description for POST/credit-transfers.

Note: These codes are for Sandbox only.

    *) For these test scenario's use the following values for the Digest and Signature header:

GET Payment Status for Business Bulk Payment Initiation.

You can retrieve the status information for a payment initiation using a GET status request.

`    {
      <?xml version="1.0" encoding="UTF-8"?>
      <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.002.001.03">
         <CstmrPmtStsRpt>
              <GrpHdr>
                  <MsgId>RABO-PAIN002-PO-0000000001865281814</MsgId>
                  <CreDtTm>2021-08-09T15:39:03.808</CreDtTm>
                  <InitgPty>
                      <Id>
                          <OrgId>
                              <BICOrBEI>RABONL2U</BICOrBEI>
                          </OrgId>
                      </Id>
                  </InitgPty>
              </GrpHdr>
              <OrgnlGrpInfAndSts>
                  <OrgnlMsgId>MMMM20211231v1</OrgnlMsgId>
                  <OrgnlMsgNmId>PAIN.001.001.03</OrgnlMsgNmId>
                  <OrgnlCreDtTm>2013-07-18T10:00:00.000</OrgnlCreDtTm>
                  <OrgnlNbOfTxs>2</OrgnlNbOfTxs>
                  <OrgnlCtrlSum>0.03</OrgnlCtrlSum>
                  <GrpSts>ACTC</GrpSts>
              </OrgnlGrpInfAndSts>
              <OrgnlPmtInfAndSts>
                  <OrgnlPmtInfId>PmtInfId-MM20211231-1</OrgnlPmtInfId>
                  <OrgnlNbOfTxs>1</OrgnlNbOfTxs>
                  <PmtInfSts>ACSC</PmtInfSts>
              </OrgnlPmtInfAndSts>
              <OrgnlPmtInfAndSts>
                  <OrgnlPmtInfId>PmtInfId-MM20211231-2</OrgnlPmtInfId>
                  <OrgnlNbOfTxs>1</OrgnlNbOfTxs>
                  <PmtInfSts>ACSC</PmtInfSts>
              </OrgnlPmtInfAndSts>
         </CstmrPmtStsRpt>
      </Document>
    }
   `

Some scenarios, as mentioned below, require specific paymentId(s) in the URL, example: (/payments/bulk/credit-transfers/\{paymentId}/status) to get the mentioned responses.

Note: These codes are for Sandbox only.

*) For this test scenario use the following values for the Digest and Signature header:

Response Status

Here is a description of the expected response statuses:

Statuses present in the POST response

• RCVD: Payment file received
• RJCT: Payment file rejected

Statuses present in the GET response

Interchange status/group status:

• ACTC: Payment succesfully created
• RJCT: Payment rejected.

Batch status:

• RCVD: Payment batch received.
• ACTC: Awaiting authorization.
• ACCP: Payment authorized.
• ACSC: Payment processed.
• RJCT: Payment rejected, expired, or cancelled.
• PDNG: Payment pending.

Transaction status on individual payment in the batch:

• RJCT: Payment rejected.
• ACCP: Payment authorized.
• CANC: Payment withdrawn.
• PDNG: Payment pending.
• ACSC: Payment processed.