Hello, I’m Guillaume! I’m a software engineering intern at TESOBE and in today’s video we are going to see how we can send a SEPA Payment Recall through the OBP SEPA adapter.
In the SEPA scheme, a Payment Recall is used to send a refund request after we have sent a transaction and for any reason you want to get the funds back, so you send a recall request to the beneficiary and the beneficiary can accept or reject this request.
So, let’s say that we have already sent a credit transfer transaction and that we want to send a recall for this transaction. With the OBP API and the SEPA Adapter, we can first create a Refund Transaction Request using the two fields and we are also going to say which is the original credit transfer transaction.
This is going to save the refund transaction in the OBP database with a forwarded status. A forwarded status means that we need to wait for the counterparty’s response. In this case this is the beneficiary or the beneficiary’s bank’s response, to say if the transaction request is completed, in which case it’s going to lead to a real payment, or rejected.
So, then the OBP API is going to send a Notify Transaction Request message to the OBP SEPA Adapter and the OBP SEPA adapter is going to store this as a recall message by finding the link between the original transaction and the recall message, and then the SEPA adapter sends the recall file.
So ok, that’s the process to send a recall file to the beneficiary bank and now we want the beneficiary bank’s response. In case the beneficiary bank or the beneficiary accepts the recall, so accept to refund the transaction, we are going to receive a return file with a Reason Code-specific Following Cancellation Request. The OBP SEPA adapter is going to save this payment return and identify the original transaction and the original recall message, just to find which transaction request in OBP this return is linked with.
Once the transaction request is identified, the OBP SEPA adapter calls the OBP API to complete the transaction request challenge. Once it’s complete, the transaction request is updated with a completed status. And when a transaction request passes to the completed status, the OBP API sends a Make payment message to the OBP SEPA adapter, which is going to save the refund transaction in the OBP API. And up to this moment, the application will be able to see the transaction refund.
But sometimes the beneficiary can reject the transaction recall and we receive a Recall Negative Answer file, this is a kind of message in the SEPA scheme. We are going here also to make a link with the original transaction and the Payment Recall transaction request. And we are going to call the OBP API to reject the transaction request challenge.
This is going to update the transaction request status to a rejected status. So the app could then see that the transaction request is passed to a rejected status with also the Reason Code and all the additional information needed.
So, let’s do this. So we are now in this step. We are going to send a credit transfer payment. So just to show you, I have an account with an IBAN, I also have the OBP API running on the SEPA Adapter. So, let’s make a payment of about €100 to my beneficiary. So I send this amount, ok. So this credits instantly a transaction, so now on the OBP credit transfer transaction we can find this transaction with an unprocessed message.
So we send the original transaction by processing this outgoing file. So until there, there is nothing new. Ok, so we have sent the original transaction.
So now we want to send the recall file. So we are going to create the refund transaction on the OBP API. So we send the recall transaction to a counterparty IBAN, we set here the original amount of our transaction, which is €100, the refund description, for example “I made a mistake on the account”, and the transaction ID, which is there.
So you can also find this transaction ID by making a request to get it, you see that it’s correct. And we need a Reason Code, so we need here a Recall Reason Code. So the SEPA scheme defines some of them, I have stored them in the adapter… the Recall Reason Code. And in this case we are going to say that we have sent that original transaction to a bad account, so we are going to use this value which means invalid creditor account number, so AC03.
Ok, so we can now send this. So as you can see, we have no transaction IDs because it’s just a transaction request at the moment. And we can see that this transaction request is on the forwarded status, which means that we are waiting for the beneficiary bank’s response to say if they accept or refuse the recall.
Ok, so we are going also to process the recall message which appears now. Ok it’s this one which has been created.
Ok, so this was the original transaction output file and this is our recall transaction outgoing file. As we can see we have here the original transaction on the Reason Code. So now, we want to get a response from the bank and we are going to receive a message. So we are going to receive a reason file, so let’s before create this file with the information in the recall.
So the amount is OK, what I mainly need is the original message ID, which is the same as this one. So we are currently creating the return file… OK. And, something really important is the transaction ID because it’s on this ID that we are going to match then here to find the original transaction and the transaction request linked with this transaction ID.
And we used the Reason Code FOCR, which means Following Cancellation Request, as you can see here, to say “Ok, this is a response to a cancellation request.
And all this information is the original transaction. Ok, so we are going to process this incoming file, so we are going to process a return file so it’s pacs.004.001.02.xml, so this one. And we are going to process it, here.
Ok so as you can see, all have been processed as well. So what happened – I’ll return to the scheme – we processed the payment return, so now we can see here in the SEPA message the pacs.004 which is the return message.
In the SEPA adapter we always have only one transaction because we make a reference to this transaction, the only things that change are the custom fields, which are changed every time we receive data, a message, for example we have here the payment return information and the Payment Recall information.
So if we take the original transaction request that was forwarded, we can now send a request and see that it’s completed. And, if I go to the transaction, so I can now get the transaction, I can see… this is a refund transaction, so as you can see this is a credit, the original transaction was a debit. And I have the transaction description, which is “Ok, the beneficiary accepts to recall the transaction”.
Ok, so that’s all good and that’s working, as you can see that’s working for the situation so we can get the transaction and also the transaction request. So now, we want the beneficiary bank to send a reject message. So we are going to take all of the first task and we are going to change the amount just to make a difference between the transactions.
Ok, so now I want to send €66 to this counterparty so I send it. Now I want to send a recall. So I need the transaction ID there… ok. And for the same reason. Here we are just going to change the beneficiary response.
Ok, I send the recall, as you can see it’s also forwarded. So if we go in the OBP SEPA adapter, we can process outgoing files and this is going to process two files: the original transaction, which is this one as you can see with €66 amount, and the recall one, because we have processed them at the same moment.
And now, let’s say that the beneficiary bank or the beneficiary don’t want to send the money back. So, for this, the beneficiary bank is going to use a payment Recall Negative Answer message, and the SEPA code for this message is camt.029.001.03, and we are going to fill it with the information of the original message. So the original message ID, and the original transaction ID.
Ok, and we are going to say that this message is coming from the beneficiary. CUST means that the reject is coming from the customer with an additional transaction. So for example, I know I don’t want to send back this money because the original recall was saying I sent the money to a bad account number and, for example, as the reject for the recall description we can say “Ok I don’t want to send the money back”, so I have already completed this.
So, now we want to integrate this reject file in our SEPA adapter, so we go here in the incoming file Actor and we want to process a camt.029.001.03.xml. Perfect. So, let’s now process this. So this is a reject message, so what just happened is a rejection. So here we have the reject for the transaction request challenge response, and as we can see it now has a rejected status.
So if I take the transaction ID, and on my API I make a request on this transaction request, I can I have all the information, I can see that it’s rejected, I can see my original recall message, I can see that it was a refund for this transaction ID, and I’ve also, in the description, so as I said in the videos before, all the information should be in the next time to be integrated as transaction request attribute.
So we have the original Reason Code and we also have the refund reject Reason Code CUST, which means that this reject is coming from a customer decision, and we have the refund reject additional information. So “No, I don’t want to send you your money back.”
And if we go to the transactions, we should have only 3 transactions, so of course the first one where we sent the original €100 transaction, the second one where we get the €100 transaction refunded, and the last one, which is the second original transaction.
But we don’t have any credit or any refund for this transaction because the transaction request here has been rejected and we have all the information we need to understand why it has been rejected.
So if we go back on the scheme, we are now in this case so we can get the Refund Transaction Request.
I hope all of this demonstration was clear, and I thank you for listening, bye.