---
title: "Paylinks Redirect and Webhooks"
slug: "paylinks-redirect-and-webhooks"
updated: 2026-09-24T10:56:20Z
published: 2026-09-24T10:56:20Z
canonical: "api-docs.blinkpayment.co.uk/paylinks-redirect-and-webhooks"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://api-docs.blinkpayment.co.uk/llms.txt
> Use this file to discover all available pages before exploring further.

# Paylinks Redirect and Webhooks

The Paylink API allows you to redirect users to your own webpage after a payment has been completed and send a webhook to your chosen endpoint.

Use `redirect_url` to return a customer to your website after a Paylink payment. Use `notification_url` to receive Paylink updates on your server, even if the customer does not return to your site.

## Redirect URL

When creating a Paylink, you can provide a `redirect_url`. After the payment is completed, the customer will be redirected to the specified URL with the following query parameters:

- `customerName`: The name of the customer the Paylink was created for.
- `status`: Indicates whether the Paylink has been paid or requires another payment attempt.
- `amount`: The amount paid by the customer.
- `reference`: The `transaction_unique` entered when creating the Paylink.

#### Example redirect after payment

`https://example.com/payment/result?customerName=Jane%20Smith&status=Paid&amount=12.50&reference=INV-1001`

## Notification URL

Set `notification_url` when creating the Paylink, for example, `https://example.com/webhooks/paylinks`. Use a publicly reachable HTTPS endpoint.

Blink sends an `HTTP POST` request with `Content-Type: application/json`.

When a Paylink has been successfully paid, Blink Payment sends a `POST` request to the endpoint provided when the Paylink was created. The request body contains the following:

- `transaction_id`: The identifier of the transaction made from this Paylink.
- `paylink_id`: The identifier for this Paylink. Use this ID to retrieve more information about the Paylink.
- `name`: The name of the customer the Paylink was created for.
- `reference`: The `transaction_unique` entered when creating the Paylink.
- `amount`: The amount paid through the Paylink.
- `payment_method`: The payment method used by the customer. Possible values are:
  - `card`
  - `open-banking`
  - `direct-debit`
- `status`: The status of the Paylink, for example, *Paid*.
- `note`: The note entered when creating the Paylink.

#### Example Paylink notification body

```json
{
  "event_type": "paylink_status_change",
  "transaction_id": "BL-00A1B2C3D4",
  "paylink_id": "123",
  "name": "Jane Smith",
  "amount": "12.50",
  "reference": "INV-1001",
  "payment_method": "card",
  "status": "Paid"
}
```

Unpaid notifications are not sent. *Partially Paid* applies only to Paylinks: a successful payment below the requested amount closes the link to further payments.

#### Responding to webhooks and retries

Acknowledge the webhook with `HTTP 200`, `201`, `202`, or `204`. The response body is ignored. All other status codes count as failures, including other 2xx responses and redirects. Blink does not follow redirects.

For example:

`HTTP/1.1 204 No Content`

Failed deliveries are attempted up to five times in total, approximately 310 seconds apart, with no increasing backoff. Connection errors, timeouts, and unsuccessful responses follow the same retry rules. Worker failures may consume an attempt before a request reaches your endpoint.

Respond promptly: connection timeouts are 5 seconds, and read timeouts are 10 seconds. Your endpoint should also handle duplicate notifications safely.

After all retry attempts have been exhausted, failed messages are retained for 14 days. Restoring the endpoint does not automatically replay them.

Recovery notifications may contain fewer fields and can omit `event_type`, `amount`, and `payment_method`. Empty fields are omitted. Where no transaction is associated with the notification, the body uses `id`, `status`, and `paylink_url` instead. Your endpoint should allow for these variations.