Integrate your own checkout directly with our API and allow your customers to make online payments with cards. Make sure you never store, process or send sensitive card data if your environment is not PCI compliant. Compliancy is guaranteed by using our client-side encryption library or by using our checkout.

🚧

Please check our client-side encryption topic on how to encrypt your card data for these endpoints!

How does it work?

In our API we expose a separate endpoint for Maestro due to legacy reasons. So we currently have https://example.com/api/v1/paymentmethods/creditcard/v1/transactions and https://example.com/api/v1/paymentmethods/maestro/v1/transactions. Both endpoints are, beside the URL exactly the same.

1. The consumer chooses to pay with Credit Card or Maestro, fills in the cardholder name, their card number (also referred to as PAN), the card expiry date and the CVC code and submits the data.
2. You need to include our client-side encryption library into your checkout and encrypt the data mentioned above by executing the encrypt function as described in our client-side encryption library page.
3. Initiate a Credit Card or Maestro payment by either invoking the create credit card or create Maestro transaction endpoint. A transaction will be created with the status OPEN. Then redirect the consumer to the given URL in the response field action.redirect.url.
4. The consumer will optionally be asked to handle the 3D secure authentication. You can use one of these OTP codes on our acceptance environment to mimic different outcomes. Eventually they will be redirected to the returnUrl you specified in the create credit card transaction (3). The payments status will be set to either AUTHORIZED, SUCCESS, CANCELLED, EXPIRED or FAILURE.
5. If you requested to be updated through webhook calls in the webhooks in the create credit card transaction request (3) you will receive a webhook call when the payment status has changed on the URL(s) specified in the create transaction call. If you didn't requested to be updated through webhooks, you can poll for the result through the get transaction endpoint .
6. You need to fetch the latest status of your transaction and inform the consumer about this final status. This can be done after you received the webhook call or by polling.

📘

When using webhooks, be aware that they are only a "best effort" mechanism. Find more details here.

Refunds

A card payment can be refunded through the creditcard refund endpoint and will be send to the acquirer who authorised the former made authorization. The refunds object returned in the response contains 2 fields. The refundedAmount field indicates the amount that is payed to the consumer. The refundedPendingAmount indicates the amount requested but not yet paid to the consumer. When multiple refunds are created, you will receive the sum of amounts in the response.

Statuses

The cards payment can have multiple statuses which are important for you to act upon.

• OPEN - The final result is not yet known. A subsequent request is required to obtain the final status. This is the status you will receive after creating a card transaction .
• CANCELLED - The consumer has cancelled the payment. No payment has been made.
• EXPIRED - The payment wasn't finished yet and the expiresAt date (send in during the creation of the transaction) has passed. No payment has been made.
• FAILURE - Something else in the process went wrong. No payment has been made.
• AUTHORIZED - The card payment is accepted by the issuer, but not yet captured by us.
• SUCCESS - Positive result. The payment is guaranteed.

All card transactions will transition from OPEN to one of the other statuses. Only the OPEN status is received in the create transaction response. All other statuses have to be fetched from the GET transaction endpoint .