Skip to main content

Payment Flow

This page describes the standard payment collection flow using Paysera Checkout API.

Overview

Payment collection consists of two related methods:

  1. Standard payment collection flow - Completed by user interaction
  2. Recurring billing flow - Automated and made from your project via API calls

Both approaches begin with initializing a Payment Request, but differ in how payments are finalized.

Standard Payment Flow

The standard payment flow involves four main steps:

Step 1: Create Payment Request

Create a payment request via POST to /checkout/rest/v1/payment-requests

Required parameters:

  • business_id - Your business identifier
  • order_id - Your unique order reference
  • price - Amount and currency
  • description - Payment description
  • method_key - Payment method (e.g., "card")
  • payer - Customer email
  • locale - Language code (e.g., "en")
  • accept_url - Redirect URL after successful payment
  • cancel_url - Redirect URL if payment is canceled
  • callback_url - URL for payment notifications

For recurring billing, add:

{
"token_strategy": "required"
}

Response contains:

  • id - Payment request ID
  • authorization_url - URL to redirect customer
  • status - Initial status "new"

Step 2: Redirect Customer

Redirect the customer to the authorization_url received in Step 1.

What happens:

  • Customer selects payment method
  • Completes payment at payment provider
  • After completion, customer is redirected to your accept_url
  • If canceled, customer is redirected to cancel_url

Step 3: Receive Notification

Paysera sends a POST request to your callback_url with a notification_id parameter.

Example callback:

POST https://yoursite.com/payment/callback
Content-Type: application/x-www-form-urlencoded

notification_id=12345

Your server must:

  1. Retrieve notification details: GET /notification/rest/v1/notifications/{notification_id}
  2. Check the event field (e.g., "payment_request.captured")
  3. Verify status is "captured"
  4. Process the payment in your system

Notification response contains:

  • event - Event type. Possible values:
    • payment_request.captured - payment was completed and funds were captured
    • payment_request.checkout_token_issued - a recurring billing token was issued without capturing funds (used together with parameters.refund_on_capture: true, see Recurring Billing Flow)
  • status - Notification status (new or read)
  • data.payment_request - The Payment Request resource. Contains, among others:
    • status - Payment status
    • order_id
    • price / price_paid - Amount and currency
    • payer - Customer information (name, surname, account_number if available)
    • issued_token - Token for recurring payments (only when token_strategy: "required" was set on the initial Payment Request)

Step 4: Mark Notification as Read

After processing, mark the notification as read: PUT /notification/rest/v1/notifications/{notification_id}/read

Critical

You must mark notifications as read. If you don't, Paysera will retry the callback multiple times until it's marked as read.

Payment Request Statuses

Payment requests have the following statuses:

  • new - Payment request created, awaiting customer payment
  • captured - Payment successfully completed
  • canceled - Payment was refunded or canceled

Notification Statuses

Notifications have their own status lifecycle:

  • new - Notification created, not yet processed
  • read - Notification has been marked as processed

API Endpoints

Payment Request API:

  • Host: checkout-eu-a.paysera.com
  • Create: POST /checkout/rest/v1/payment-requests

Notification Event API:

  • Host: checkout-eu-a.paysera.com
  • Get notification: GET /notification/rest/v1/notifications/{id}
  • Mark as read: PUT /notification/rest/v1/notifications/{id}/read

Authentication: All requests require MAC authentication headers.

Flow Diagram

┌─────────────────────────────────────────────────────────────┐
│ Step 1: Create Payment Request │
│ POST /checkout/rest/v1/payment-requests │
│ → Receive authorization_url │
└──────────────────────┬──────────────────────────────────────┘


┌─────────────────────────────────────────────────────────────┐
│ Step 2: Redirect Customer │
│ → Customer goes to authorization_url │
│ → Customer completes payment │
│ → Customer redirected to accept_url or cancel_url │
└──────────────────────┬──────────────────────────────────────┘


┌─────────────────────────────────────────────────────────────┐
│ Step 3: Receive Notification (async) │
│ POST to your callback_url with notification_id │
│ → GET /notification/rest/v1/notifications/{id} │
│ → Check event: "payment_request.captured" │
│ → Extract payment details and issued_token │
└──────────────────────┬──────────────────────────────────────┘


┌─────────────────────────────────────────────────────────────┐
│ Step 4: Mark as Read │
│ PUT /notification/rest/v1/notifications/{id}/read │
│ → Prevent callback retries │
└─────────────────────────────────────────────────────────────┘

Important Notes

  • Domain provided with credentials: The API domain is provided together with your credentials
  • Token strategy: If you want recurring billing, use "token_strategy": "required" in the initial payment request
  • Supported payment methods: When using token_strategy, only payment methods that support tokens are available
  • Callback retries: Callbacks will be repeated multiple times until marked as read
  • Libraries available: Use official Paysera libraries for easier integration

Next Steps