v1.0

Recurring Payments#

Charge customers on a schedule using stored card data from an initial transaction.

Setup — Initial Transaction#

Add recurring_init=Y to the initial SALE request. If the transaction succeeds, the response and callback include a recurring_token. Store this token against the customer record.

ℹ️
Only the test card 4111111111111111 with expiry 01/2038 supports recurring token generation in sandbox. Other test cards will not return a recurring token.

RECURRING_SALE#

Creates a new transaction using stored cardholder data from a previous operation. Uses Formula 1 for the hash.

POST https://{PAYMENT_URL}/post
ParameterDescriptionRequired
actionRECURRING_SALEYes
client_keyYour account key (UUID)Yes
order_idNew unique order ID for this chargeYes
order_amountAmount to chargeYes
order_currencyCurrency codeYes
order_descriptionDescription for this chargeYes
recurring_first_trans_idTransaction ID of the primary transactionYes
recurring_tokenToken from original transactionYes
schedule_idLink to a schedule objectNo
authY for auth-onlyNo
hashFormula 1Yes

Response is identical to SALE (with action=RECURRING_SALE).

⚠️
Hash requires original card data. Formula 1 uses the first 6 and last 4 digits of the card number. Since RECURRING_SALE does not send card fields, you must store the card first 6 + last 4 digits (or the card mask from the initial SALE callback) alongside the recurring_token to compute hashes for subsequent charges. You also need the payer's email from the initial transaction.
⚠️
Recurring transactions bypass 3DS. Ensure your agreement with the cardholder authorises recurring charges, and your acquiring setup supports MIT (Merchant Initiated Transactions).

RETRY#

Retry a soft-declined recurring transaction. Only valid for soft declines — hard declines (stolen card, fraud) will not succeed. Check decline_reason before retrying.

ParameterDescriptionRequired
actionRETRYYes
client_keyYour account keyYes
trans_idTransaction ID of the declined recurring transactionYes
hashFormula 1Yes

Synchronous response returns result: ACCEPTED. Final result delivered via callback with action: RETRY.

Schedule Management#

Schedules automate recurring charges at defined intervals. All schedule operations use POST https://{PAYMENT_URL}/post.

ActionPurposeHash
CREATE_SCHEDULECreate a new schedule with name, interval, payment countFormula 3
PAUSE_SCHEDULESuspend scheduled paymentsFormula 4
RUN_SCHEDULEResume a paused scheduleFormula 4
DELETE_SCHEDULEPermanently delete a scheduleFormula 4
SCHEDULE_INFOGet schedule detailsFormula 4
DESCHEDULEStop payments by schedule (requires recurring_token + schedule_id)Formula 4

CREATE_SCHEDULE Parameters

ParameterDescriptionRequired
actionCREATE_SCHEDULEYes
client_keyYour account keyYes
nameSchedule name (up to 100 chars)Yes
interval_lengthHow often payments occur (cannot be 0)Yes
interval_unitday or monthYes
day_of_month1–31; only if interval_unit=month. If 29/30/31 and month is shorter, last day is usedNo
payments_countTotal number of paymentsYes
delaysNumber of skipped intervals before cycle startsNo
hashFormula 3Yes

Response returns schedule_id which you pass to SALE or RECURRING_SALE via the schedule_id parameter.

Full parameter tables for all schedule operations are in the API Reference.