Repeat Payment

Repeat payment schedules are those where the user supplies the required setup information (including a card for payment), and the payments are executed automatically on a recurring basis.

There are two types of repeat payment schedules.

Fixed Scheduled Repeat Payment - In this scenario, each payment is taken at a regular frequency for a fixed amount.
Variable Scheduled Repeat Payment - In this scenario, each payment’s date and amount set is completely different.

Both schedules can be created using the ECOM or MOTO method

There are two methods to create a repeat payment schedule.

ECOM - This means that the card details are being entered on a secure payment page by the Customer

These are designed for you to accept payments via a website, such as a shopping cart payment.
This ECOM method will use advance fraud detection of 3-D Secure.

3-D Secure will return a acsform, which is a HTML form used to perform the 3-D Secure authentication.

A HTML page should be send to the user which include the acsform in the body and the following JS in the header:

<script>
  onload = () => document.forms[0].submit();
</script>

The user will complete the 3-D Secure form and submit.

After submission, the user will be redirected to the predefined return URL with an encoded repeat schedule ID.

MOTO - This means that the card details are being entered on a secure payment page by the Merchant

These are designed for you to build your own virtual terminal system to enter remote order details. This MOTO method doesnt use a 3-D Secure authentication as the cardholder is not able to perform the challenge.

Once the payment is processed the user will get json response with all the repeat schedule related data.

Each request is authenticated using HTTP Basic Auth by adding a bearer token to the header, e.g. Authentication: Bearer {{access_token}}. You can get the {{access_token}} from the create token request.

Before creating a repeat payment schedule, a Payment_intent needs to be generated from the create intent request.

The ccElement is passed as part of the response, which can be implemented to generate the payment form and paymentToken ( tokenised card value) from there.

In a PHP implementation, the payment page may look like this:

<head>
  ...
  <script src="https://code.jquery.com/jquery-3.6.3.min.js"></script>
  <script src="https://gateway2.blinkpayment.co.uk/sdk/web/v1/js/hostedfields.min.js"></script>
  <script src="https://secure.blinkpayment.co.uk/assets/js/api/custom.js"></script>
  ...
</head>

<body>
    <form method="POST" action="update" id="payment">
        @csrf
        {!! $ccElement !!}
        <button type="submit">Submit</button>
    </form>
</body>

Resources

POST /pay/v1/repeat-payments for MOTO
POST /pay/v1/repeat-payments for ECOM
GET /pay/v1/repeat-payments
GET /pay/v1/repeat-payments/{id}
DELETE /pay/v1/repeat-payments/{id}
DELETE /pay/v1/repeat-payments/cancel/{id}
POST /pay/v1/repeat-payments/retry/{id}

Create Repeat Payment using MOTO

Create a repeat payment schedule.
A schedule can either be on a Variable or Fixed basis

POST /pay/v1/repeat-payments

Headers

Content-Type string
Content type.

Authorization string
Access token generated from create token request.

Attributes - (Required for all schedules)

payment_type string
Repeat payment type. It must be either of the following values.

fixed_schedule
variable_schedule

payment_intent string
Payment intent generated from create intent request.

paymentToken string
Tokenised card value. In create intent response, ccElement will be returned in element array if repeat payment is enabled for that merchant account. User can populate ccElement as a part of the create repeat request form to generate and pass paymentToken value. Please go through the process from payment page, to generate paymentToken.

customer_name string
Customer name.

customer_email string
Customer email.

reference string
Reference value. Unique textual details of the schedule

customer_address string
Customer address.

customer_postcode string
Customer postcode.

currency string
Currency that the payments will be processed in

Specific fields for a Fixed schedule - (These cannot be used in conjunction with the below Variable schedule specific fields)

frequency string
Payment cycle frequency. It is required when creating a Fixed Schedule.
Possible values are

days
weeks
months

frequency_duration integer
Payment frequency duration. It is required when creating a Fixed Schedule.
(E.g. “2” and “days” will be every 2 days)

start_payment_date date
Date on which the first payment will be captured.
It is required when creating a Fixed Schedule.
Default value set to today.

first_amount decimal (optional)
First payment amount.
When creating a Fixed Schedule, the first amount value can be customised.

recurring_amount decimal
Recurring amount for each instalment. It is required when creating a Fixed Schedule.

is_limited_installments boolean
When creating a Fixed Schedule, it is required to mention if the schedule will have unlimited or limited instalments.
Possible values are

true
false

installments integer
Number of installments.
It is required when creating a Fixed Schedule if the is_limited_installments field is true (i.e. it has limited instalments)

If is_limited_installments is true, then these 2 fields can also be added

If is_limited_installments is true, then these 2 fields can also be added

final_amount decimal (optional)
Final payment amount.
This can be used when creating a Fixed Schedule if there are limited instalments.
If there are unlimited instalments, this field should not be used.

final_payment_date date (optional)
Date on which the final payment will be captured.
Final date can be customised along with the final amount when creating a Fixed Schedule.
This can only be used if there are limited instalments. If there are unlimited instalments, this field should not be used.
This date must be after the start payment date and also after the 2nd last recurring date.

Specific fields for a Variable schedule - (This cannot be used in conjunction with any of the above Fixed schedule specific fields)

schedule_set array
Schedule set is a array set of date and amount where the date will be the key and the amount will be its value.
It is required for Variable Schedule payment. This array needs to have minimum 2 set of values.

Request for fixed schedule

POST https://secure.blinkpayment.co.uk/api/pay/v1/repeat-payments HTTP/1.1
Content-Type: application/json
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbG...

{
    "payment_type": "fixed_schedule",
    "payment_intent": "pi_rj..........",
    "customer_name": "Test developer",
    "customer_email": "test@gmail.com",
    "reference": "schedule payment with limited installments",
    "customer_address": "Uk....",
    "customer_postcode": "119083",
    "frequency": "days",
    "frequency_duration": 1,
    "currency": "GBP",
    "first_amount": 20.03,
    "recurring_amount": 15.01,
    "final_amount": 10.08,
    "is_limited_installments": true,
    "installments": 3,
    "start_payment_date": "23-02-2023",
    "final_payment_date": "25-02-2023",
    "paymentToken": "ey............"
}

Response

Request for variable schedule

Response

Create Repeat Payment Using ECOM

Create a repeat payment schedule.
A schedule can either be on a Variable or Fixed basis

POST /pay/v1/repeat-payments

Headers

Content-Type string
Content type.

Authorization string
Access token generated from create token request.

User-Agent string
User agent.

Accept string
Accept

Accept-Encoding string
Accept encoding.

Accept-Charset string
Accept charset.

Attributes - (required for all schedules)

payment_type string
Repeat payment type. It must be either of the following values.

fixed_schedule
variable_schedule

payment_intent string
Payment intent generated from create intent request.

paymentToken string
Tokenised card value. In create intent response, ccElement will be returned in element array if repeat payment is enabled for that merchant account. User can populate ccElement as a part of the create repeat request form to generate and pass paymentToken value. Please go through the process from payment page, to generate paymentToken.

customer_name string
Customer name.

customer_email string
Customer email.

reference string
Reference value. Unique textual details of the schedule

customer_address string
Customer address.

customer_postcode string
Customer postcode.

currency string
Currency that the payments will be processed in

Specific fields for a Fixed schedule - (These cannot be used in conjunction with the below Variable schedule specific fields)

frequency string
Payment cycle frequency. It is required when creating a Fixed Schedule.
Possible values are

days
weeks
months

frequency_duration integer
Payment frequency duration. It is required when creating a Fixed Schedule.
(E.g. “2” and “days” will be every 2 days)

start_payment_date date
Date on which the first payment will be captured.
It is required when creating a Fixed Schedule.
Default value set to today.

first_amount decimal (optional)
First payment amount.
When creating a Fixed Schedule, the first amount value can be customised.

recurring_amount decimal
Recurring amount for each instalment. It is required when creating a Fixed Schedule.

is_limited_installments boolean
When creating a Fixed Schedule, it is required to mention if the schedule will have unlimited or limited instalments.
Possible values are

true
false

installments integer
Number of installments.
It is required when creating a Fixed Schedule if the is_limited_installments field is true (i.e. it has limited instalments)

If is_limited_installments is true, then these 2 fields can also be added

If is_limited_installments is true, then these 2 fields can also be added

final_amount decimal (optional)
Final payment amount.
This can be used when creating a Fixed Schedule if there are limited instalments.
If there are unlimited instalments, this field should not be used.

final_payment_date date (optional)
Date on which the final payment will be captured.
Final date can be customised along with the final amount when creating a Fixed Schedule.
This can only be used if there are limited instalments. If there are unlimited instalments, this field should not be used.
This date must be after the start payment date and also after the 2nd last recurring date.

Specific fields for a Variable schedule - (This cannot be used in conjunction with any of the above Fixed schedule specific fields)

schedule_set array
Schedule set is a array set of date and amount where the date will be the key and the amount will be its value.
It is required for Variable Schedule payment. This array needs to have minimum 2 set of values.

Specific fields for ECOM

device_timezone integer
Device timezone value which can be fetched using javascript and assigned to the respective hosted input field. This value is required in 3DS.

device_capabilities string
Device capabilities which can be fetched using javascript and assigned to the respective hosted input field. This value is required in 3DS.

device_accept_language string
Device accept language which can be fetched using javascript and assigned to the respective hosted input field. This value is required in 3DS.

device_screen_resolution string
Device accept language which can be fetched using javascript and assigned to the respective hosted input field. This value is required in 3DS.

remote_address string
Remote address which can be fetched using javascript and assigned to the respective hosted input field. This value is required in 3DS.

Request for fixed schedule

Response

HTML Page

Request for variable schedule

Response

Get all repeat payments

Get the details of all the repeat payment schedules created from the same account.

The results can be filtered by using the below query parameters. payment_type need to be passed as query param without which the results can't be fetched.

GET /pay/v1/pay/repeat-payments

Headers

Content-Type string
Content type.

Authorization string
Access token generated from create token request.

Query parameters

payment_type string
Repeat payment type.

fixed_schedule
variable_schedule

page integer (optional)
Page Number.

status string (optional)
Repeat payment status.

Active - This means the payments have started
Pending - This means the first payment has not yet been processed
Cancelled - This means the schedule has been cancelled. No further payments will be processed
Completed - This means all the payments have been processed. No further payments will be processed

Request

Response

Get repeat payment

Get details of a specific repeat payment schedule using id.

GET /pay/v1/pay/repeat-payments/{id}

Headers

Content-Type string
Content type.

Authorization string
Access token generated from create token request.

Query parameters

payment_type string
Repeat payment type.

fixed_schedule
variable_schedule

Request

Response

Delete a scheduled payment/Cancel all remaining payments

This can be used:

To delete a schedule and all its remaining payments that havent been processed yet, using just the main schedule id
To delete a specific future payment from a schedule, using the id and the recurring_id

The schedule id and recurring_id can be fetched from get repeat payment request.

This will delete the future payment from both fixed and variable schedules.

DELETE /pay/v1/repeat-payments/{id}

Headers

Content-Type string
Content type.

Authorization string
Access token generated from create token request.

Attributes

payment_type string
Repeat payment type. It must be either of the following values. It is passed to identify the type of the specific repeat payment.

fixed_schedule
variable_schedule

recurring_id integer (optional)
Recurring id is need to be passed to delete a specific recurring event of Fixed and Variable schedule payment.

Request

Response

Refund a processed payment

Refund any processed repeat payment using repeat schedule id and recurring id.

In this scenario, the id (repeat schedule id) needs to be passed in the request url, with the recurring_id and payment_type in the request body.

This request can be used to refund a processed payment that has a captured or completed status

DELETE /pay/v1/repeat-payments/cancel/{id}

Headers

Content-Type string
Content type.

Authorization string
Access token generated from create token request.

Attributes

payment_type string
Repeat payment type. It must be either of the following values. It is passed to identify the type of the specific repeat payment.

fixed_schedule
variable_schedule

recurring_id integer
Recurring id needs to be passed to refund a specific payment from a Fixed or Variable schedule.

Request

Response

Retry a processed payment that failed

Retry any specific payment which was able to run on the scheduled day but returned a declined status due to some issue for that Repeat schedule.

This will run the payment for both fixed and variable schedules.
In this scenario, the recurring_id (fetched from get repeat payment request) needs to be passed in the body, along with the id (repeat schedule id) in the request url.

POST /pay/v1/repeat-payments/retry/{id}

Headers

Content-Type string
Content type.

Authorization string
Access token generated from create token request.

Attributes

payment_type string
Repeat payment type. It must be either of the following values. It is passed to identify the type of the specific repeat payment.

fixed_schedule
variable_schedule

recurring_id integer
Recurring id needs to be passed to retry a specific payment from a Fixed or Variable schedule.

Request

Response