The following guide explains how to create payments with the provided Satispay API.
Depending on the selected flow, payments experience different lifecycles.

Payment lifecycle

MATCH_CODE, MATCH_USER

These type of payments always begins in PENDING status.

They can transition to:

• ACCEPTED if:
  • the consumer accepts the payment via the Satispay App.
• CANCELED if:
  • the payment expires.
  • the user explicitly cancels the payment via the Satispay App.

ACCEPTED and CANCELED are final statuses which cannot be changed.

Show graph

PRE_AUTHORIZED, HOTP_AUTH

For this payment types, the payment will be created in ACCEPTED status.
There are no transitional states, as if the charge on the user's wallet fails, the payment won't be generated, and you will receive a 4xx status code.

FUND_LOCK

This type of payment always begins in PENDING status.

It can transition from PENDING to:

• AUTHORIZED if:
  • the consumer authorizes the fund lock payment via the Satispay App.
• CANCELED if:
  • the user explicitly cancels the payment via the Satispay App.
  • the payment expires.

Once the payment status is in AUTHORIZED, it can transition to:

• ACCEPTED if:
  • the merchant accepts it via an ACCEPT action using the Update payment API.
• CANCELED if:
  • the merchant cancels it via a CANCEL action using the Update payment API.
  • the payment expires.

ACCEPTED and CANCELED are final statuses which cannot be changed.

Show graph

PRE_AUTHORIZED_FUND_LOCK

This type of payment always begins in AUTHORIZED status.
There are no transitional states, as if the authorization on the user's wallet fails, the payment won't be generated, and you will receive a 4xx status code.

It can transition from AUTHORIZED to:

• ACCEPTED if:
  • the merchant accepts it via an ACCEPT action using the Update payment API.
• CANCELED if:
  • the merchant cancels it via a CANCEL action using the Update payment API.
  • the payment expires.

ACCEPTED and CANCELED are final statuses which cannot be changed.

Show graph

Refunds

Refunds can only be processed via our API.

To perform refunds you need to create a new payment with the REFUND flow.
You will need to send the parent_payment_uid with the payment id that you want to refund and the amount_unit that you want to refund for that specific payment.

We suggest you to fill the external_code with your internal order id, in order to better reconcile refunds in your payment reports.
This field will also be shown to the user via the Satispay app.

Refund can only be created in ACCEPTED status.
There are no transitional states, as if the refund fails, the refund won't be generated, and you will receive a 4xx status code.
If the refund goes well, you can distinguish the refund payment by using the response type property, which will be REFUND_TO_BUSINESS.

Refunds for payments with only e-money

Refunds are only possible within 365 days from the payment creation date.
It is possible to create multiple partial refunds until you reach the total amount of the payment that you want to refund.

Refunds for payments with Meal Voucher

Refunds are only possible on the same day of payment creation and for the total amount of the payment.
Partial refunds in payments with Meal Voucher are not available.

Refunds for payments with Fringe Benefits

Refunds are only possible within the same month of the payment creation and must be for the total amount. Partial refunds for payments made with Fringe Benefits are not available.

REQUEST