Business Direct Debit

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

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

Using BDD, you can optimize the customer journey in your web service.

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

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

🚧

Payment files with multiple batches can be sent to the bank using BDD 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.

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 defined per operation. The table below describes the rate limiting for this product.

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 PAIN008 file, read more about it here .

🚧

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

Response

POST Payment initiation for Business Direct Debit.

You can initiate a bulk direct debits 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/direct-debits/123e4567-e89b-42d3-a456-556642440000/status</href>
             </status>
          </_links>
          <paymentId>123e4567-e89b-42d3-a456-556642440000</paymentId>
          <transactionStatus>RCVD</transactionStatus>
      </InitiatedTransactionResponse>

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

{
       <?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/direct-debits.

Note: These codes are for Sandbox only.

For test scenarios marked with * use the following values for the Digest and Signature header:

GET Payment Status for Business Direct Debit.

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-0000000001865274433</MsgId>
                  <CreDtTm>2021-08-09T15:42:17.252</CreDtTm>
                  <InitgPty>
                      <Id>
                          <OrgId>
                              <BICOrBEI>RABONL2U</BICOrBEI>
                          </OrgId>
                      </Id>
                  </InitgPty>
              </GrpHdr>
              <OrgnlGrpInfAndSts>
                  <OrgnlMsgId>MMMM20211231v1</OrgnlMsgId>
                  <OrgnlMsgNmId>PAIN.008.001.02</OrgnlMsgNmId>
                  <OrgnlCreDtTm>2013-07-18T10:00:00.000</OrgnlCreDtTm>
                  <OrgnlNbOfTxs>1</OrgnlNbOfTxs>
                  <OrgnlCtrlSum>0.02</OrgnlCtrlSum>
                  <GrpSts>ACTC</GrpSts>
              </OrgnlGrpInfAndSts>
              <OrgnlPmtInfAndSts>
                  <OrgnlPmtInfId>PmtInfId-DD20211231-1</OrgnlPmtInfId>
                  <OrgnlNbOfTxs>1</OrgnlNbOfTxs>
                  <OrgnlCtrlSum>0.02</OrgnlCtrlSum>
                  <PmtInfSts>ACSC</PmtInfSts>
              </OrgnlPmtInfAndSts>
          </CstmrPmtStsRpt>
      </Document>
    }

Some scenarios, as mentioned below, require specific paymentId(s) in the URL, example: (/payments/bulk/direct-debits/paymentId/status) to get the mentioned responses. 

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 successfully 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.