Direct card payment

This is the integration flow for making card payments that are captured directly or within the maximum authorization time, using the Card Payment Widget.

Complete API documentation is available at: Payer B2B

Integration Flow

The following flow describes the communication between the customer's browser, the merchant server and Payer.

Integration Guide

The first step is to request a link for the card payment.

The response contains a url used for redirect or loading in iframe and a paymentId for requesting status and capture the card payment.

The payment url expires after 31 days.

After 31 days have passed, if the user has not entered card details and continued in the card payment flow (also applies if they click "Back" and lands on the backToShopURL), the link will expire and a new is required.

To cancel a payment, see Cancel a payment

Step 2. Present card input to the user

Integration guides: Card Integration Alternatives

In this step Payer will request card information from the customer and handle a potential 3d-secure verification.

Step 3. Capture Funds

Use the paymentId acquired in the authorize request to capture the card payment. It is possible capture an amount that is less than or equal to the authorized amount. The entire or remaining authorized amount will be captured if no amount is provided.

This call should not be done from the browser, since it requires the merchant’s private credentials.

The capture request will return a response containing URLs to the receipt view. These will always be null if you don’t connect the payment to an order created in Orders V2 and included in previous request (“Step 1: Create link to the Card Payment Widget”)

Cancel a payment

A payment link created in (Step 1) will be valid for 31 days if not manually canceled. After cancellation, the buyer will not be able to proceed with the payment. To cancel, send a PUT request to the following endpoint:

Bash
Copy

If successful, an empty HTTP 200 response is expected. The operation will be successful only before the payment has been authorized. A cancellation after authorization will yield a HTTP 400 response.

In a special case, where cancellation request arrives simultaneously as the buyer is processing a 3DS session, a card authorization could still go through. In this case, the authorized funds will automatically be released within an hour.

Ready for testing your integration

In Testing & Simulation page you can find cards for different test scenarios.

Type to search, ESC to discard
Type to search, ESC to discard
Type to search, ESC to discard