This endpoint can be accessed with the following API type: pos-payment
.Don't have an API key? Create one in your Customer Area with the type pos-payment
, go to Developers -> Api Credentials.
When cancelling a payment, the API key needs to have the same store ID a the payment itself.
Refunding a referenced POS payment#
To return funds to a shopper after a payment is Approved, you need to refund the payment. Referenced refunds are connected to the original payment, using the unique identifier of that payment (payment_id
).Full refund to return the total value of the purchase to the shopper.
(In talks with Adyen to provide this option) Partial refund to return part of the purchase to the shopper. For example, when a shopper returns one of the items they purchased. You can also make multiple partial refunds. For example, when a shopper returns several items at different times.
It can take up to 40 business days for the funds to be returned to the shopper's account, depending on the payment method.Refund authorization#
Refund authorization means that before processing a refund, Adyen checks with the issuer if the shopper's card or account is valid. This happens automatically; you do not have to ask for this in your refund request.As soon as the issuer authorizes the refund, the refund is visible on the shopper's account. This improves customer satisfaction and reduces the number of questions from shoppers about their refund. Also, there are less refund-related chargebacks because issuers usually return the funds to the shopper sooner.Issuers can decline a refund authorization for reasons like:When a refund authorization is declined, Adyen still tries to process the refund.Terminal & Point of sale#
By default a refund will make use of the same terminal_id
and pos_id
as the original payment. How ever you can provide new values.A refund can be processed on a different terminal_id
but the terminal needs to be online, as Adyen processes the refund on a terminal device.
Synchronous method#
There are two options: asynchronous & synchronous. We strongly advise implementing the asynchronous method.Receiving a synchronous result#
Your POS app needs to make HTTPS requests to the endpoint with the synchronous_method
value sync
. This request must use an extended timeout of more than 150 seconds. During this time the connection is kept alive, and a synchronous response will follow.
Receiving an asynchronous result#
Your POS app needs to make HTTPS requests to the endpoint with the synchronous_method
value async
. The time between making the request and receiving the event
depends on the quality of the terminal's internet connection.
To asynchronously receive the response, you need to set up event notifications. The terminal will send the response over the webhook to your event webhook endpoint.
Check the payment status#
We recommend that your integration should automatically check the status of a payment any time it fails to receive a response.Refund requests time out after a while. If you do not receive a response (or you receive a response indicating a time-out) after 150 seconds and the internet connection hasn't dropped, your integration should automatically check the payment status.Webhooks#
Event webhooks are only used for asynchronous refund requests.For an asynchronous refund request an event webhook is required.To use a webhook you need to specify the type object in the webhook object.In the type object, provide the url
, authentication_type
and the authentication type specific values.Authentication types#
3.
no_auth
(We do not endorse this authentication type)