Capture and Daily Closing
These two features are extremely important Saferpay features. Depending on the means of payment, the two can be directly associated with each other, and they must be carried out for the cash flow to be initiated to the merchant’s account. If no capture and batch has been executed, no money will be transferred.
This is why this dedicated chapter is so important. Here, we'll cover, what the capture is, how it is triggered and how you know, that it must be triggered.
To clarify one thing from the beginning: Saferpay does not support automatic capturing.
If a capture is needed, it always has to be executed by the merchant. The API allows you to automate the capture, but it is still executed by your system and not by Saferpay.
Capture
The Capture serves to book and thus to conclude/finalize a payment. As long as a transaction has not passed through the capture, the amount is merely reserved (“authorized”), but it will not be transferred to the merchant account. This is why the capture is so important.
On the API side, you receive information about the transaction via the Transaction.Status parameter, e.g. through the PaymentPage Assert, or Transaction Authorize. Transactions that have not yet been booked are visible in Saferpay Backoffice as "Reservation", Reservations are marked as "AUTHORIZED" on API-level and have to go through the Capture, to be finalized:
"Transaction": {
"Type": "PURCHASE",
"Status": "AUTHORIZED",
"Id": "MUOGAWA9pKr6rAv5dUKIbAjrCGYA",
"Date": "2015-09-18T09:19:27.078Z",
"Amount": {
"Value": "100",
"CurrencyCode": "CHF"
},
"AcquirerName": "AcquirerName",
"AcquirerReference": "Reference"
}If a transaction has already passed through, or does not need the capture, the status is changed to “CAPTURED”:
A successful Capture may only be executed once. If a second Capture is attempted, the API will throw an error, informing you, that the Capture already happened:
Note, that this error doesn't mean, that this transaction has failed. It simply means, that the capture has already been executed, so the transaction is already finalized and the money will be transferred to your bank account.
Not all payment methods need a separate capture to trigger the cash flow. The respective Payment Method chapter will give you the necessary information, if a Capture is needed. However, dynamically reacting on the Transaction.Status parameter is the preferred method, as this enables you to also react to more payment methods, that will be added to your account, down the line, with no, or just minimal code-changes.
Payment methods, that do not need the capture, will return the status "CAPTURED" right away.
Capturing a different amount and Multipart Captures
The Capture can also be used to change the amount of the transaction. It is generally possible to capture less, than initially authorized. So applying things like voucher codes, or similar, is possible. Capturing more than initially authorized, however, may result in an error and is not recommended and sometimes downright blocked. This however depends on your processor/used payment method.
It is important to note, that a Capture can only be performed once. The rest of the authorized amount will be released and can no longer be captured, if you capture less.
However, certain payment methods do support Multipart Captures, which allow you to claim the money in multiple, smaller chunks. Please refer to the given payment method chapter, to see, if Multipart Captures are supported.
What if a capture fails?
This depends on the given payment-method and the processor behind it. Generally, if an authorization is successful, the capture should not be rejected, unless the reservation-time has been exceeded, a technical problem has occurred, or the processor has very specific reasons to not accept the capture.
One example may be a suspicion of fraud, though the processor generally will reject the reservation beforehand, so that a Capture is not even needed.
However, should a Capture be rejected, you are allowed to execute another attempt at another time. The exact time-frame also depends on the payment method and its processor, but it is generally recommended perform it within 24 hours.
Should the Capture still be rejected, then please contact the support of the respective processor on that matter.
Cancel
A Cancel is the direct opposite of a capture. Instead of claiming the money, it releases the authorized amount. A Cancel should always be performed, if you no longer want to capture the money of a given transaction.
Note, that this does not apply, if you intend on using Partial Captures, as those do work in a different way, also in terms of releasing funds. Please read the chapter there, on how to handle Partial Captures.
This is also important to understand, because the Capture and the Cancel are in direct relationship to one another. Generally
Please refer to the given payment method chapter for more information, as there may be special cases.
Reservation times & Delayed Captures
While it is possible and sometimes even necessary to delay a Capture, until the goods can be shipped, a reservation, made through a certain payment processor, may only last for a limited time only. If this timeframe is exceeded, the authorized amount is released and becomes available to the account holder again. This may have the result that the amount can no longer be claimed. We recommend to Capture an authorization as soon as possible. Either by direct API call, or manually via Saferpay Backoffice.
The time-frame depends on the given payment method and your contract with your processor. Please ask there for further information. In case of Worldline (e.g. credit cards), please contact your account manager or our sales department.
Smart decision-making
Just capturing every transaction, may not be the smartest thing to do for your business. Remember: A capture not only initiates the money-flow, it also is you -the merchant- accepting this transaction and everything, that comes with it.
There are multiple things, that should be considered, when making this decision, like:
Do I have Liability Shift through 3D Secure?
Do I trust this customer?
Some countries even prohibit a capture, before the goods have been shipped to the customer. So the capture may only happen, if the goods are shipped to the payer.
These are just the most important things to consider, so please be smart about this and make the decision to capture wisely, to minimize fraud and legal troubles in certain countries.
Daily Closing
The daily closing follows the capture once daily, automatically at 22:00 CEST. During this process, all transactions that have passed through the capture are filed with the payment method processor in order. Depending on the payment processor, this is also the point, where all captured transactions are paid out to the merchant's bank account. Please contact your processor for the given payment method, if you need more information.
It also serves as a "collecting" step, where all captured transactions are filed together, which then can be viewed inside the Backoffice.
Triggering the Batch Close via API
If desired, this step can also be triggered via the Saferpay API. The request necessary for this is called Batch Close.
However, before you can use the API, you need to disable the daily closing in the Saferpay Backoffice via "Settings -> Terminals" for the respective terminal.
A Batch Close must be carried out only once a day. It is possible to do it multiple times, but it is only recommended to do so, if really needed.
If you deactivate the batch close, but then do not trigger it via API, it will lead to some transactions not being paid out, so make sure, that either one, or the other is being done.
Transaction Payout
The Capture and subsequently the Daily Closing together give the signal to the payment processor, that the merchant is ready and wants to receive the money for a given transaction. The payment service provider (PSP), in this case Saferpay, then routes this request towards the payment processor itself, for example Worldline, Pay Pal etc., so they can process the payout itself.
This processing however takes some time, as there are not only internal but also external systems involved, Saferpay has no control over, like the card holders bank. Due to that, the payout itself will always be done with a delay of a couple days.
A real-time payout is not possible.
Always cross-check with your processor
The payout is always happening on processing- and not Saferpay side. Saferpay only submits the request for the payout to be done. However the progress and status, including eventual complications, is not relayed back to Saferpay. Thus, even if a transaction has been captured and transferred through the batch close, please always check your reconciliation data in the portal of your given processor, e.g. the Acquiring Merchant Portal of Worldline and check for discrepancies.
This data contains information on all transactions, that actually have been processed and paid out successfully by the given processor.
Though rare, it can happen, that a transaction has been successfully submitted to processing by Saferpay, but certain complications lead to the payout failing.
As mentioned: Saferpay does not receive any information on that matter and unfortunately cannot help you here.
It is important to know, that Worldline can only share reconciliation-information, if the transaction has been processed through Worldline contracts and thus processing.
Other, external processors, for example Pay Pal, Postfinance etc., do offer their own solutions, that have to be used instead.
However Worldline does offer processing contracts for certain 3rd party providers, for example Twint and iDeal. Please contact your account manager, or our sales directly for further information.
If you need help on this matter:
For Worldline processing, please contact our support, so the matter can be cleared up.
In case of 3rd party processing/providers, you must contact them directly.
For transaction-identification, please make sure, that you set the Payment.OrderId whenever possible and that this ID is unique. Saferpay will forward this ID to every processor, so it may be displayed in your reconciliation-data.
This ensures, that you can easily keep track of your transactions across platforms and identify potential issues.
Last updated
Was this helpful?