Recurring Payments & Card on File

TransactDirect lets you store a customer's card securely at their first payment and charge it again later, without your systems ever holding card details. Monek returns a CrossReference for every transaction. You store that reference and send it in place of the card details when you charge the card again.

This is known as Credentials on File (COF). It covers:

• Subscriptions and memberships: a fixed amount on a regular schedule, e.g. monthly.
• Instalments: a predictable amount at regular intervals for a fixed term.
• Unscheduled charges: e.g. account top-ups or usage-based billing.

There are two kinds of stored-card payment:

Type	Who starts it	Customer present?	3-D Secure
Merchant Initiated Transaction (MIT)	Your system, e.g. a monthly billing job	No	Not performed
Cardholder Initiated Transaction (CIT)	The customer, e.g. "pay with saved card"	Yes	Required for Strong Customer Authentication (SCA)

This page focuses on recurring MITs. For older integrations using SALE_CA, see Legacy: Continuous Authority.

Before you start

1. Acquirer approval. Your acquiring bank must approve recurring transactions on your merchant account before you start.
2. Monek registration. Contact Monek Support to enable recurring payments (rebilling) on your Monek merchant account.
3. API Key. Charges using a CrossReference must include your ApiKey. Keep it private and only send it on direct server-to-server calls, never on hosted page redirects.
4. Test Merchant ID. Request one from Monek Support before you start development. See Test Cards.

note

Recurring payments are not supported on Maestro cards.

How it works

Step 1: Take the first payment

Take the first payment on the Checkout Page as a normal e-commerce sale, with 3-D Secure. Add the following fields to show the card is being stored for a recurring agreement:

Field	Value	Purpose
AcceptCOF	YES	Confirms the customer has been told, and has agreed, that their card will be stored for future payments.
CAType	R (Recurring)	Marks this as the initiating payment of a recurring agreement. See Cardholder Agreement Types.

Before sending AcceptCOF=YES, your sign-up journey must clearly tell the customer how much they'll be charged, how often, and how to cancel.

Recording the customer's consent

You can record consent in either of two ways:

Approach	Send	What the customer sees
Consent collected in your own sign-up journey (recommended for subscriptions)	AcceptCOF=YES	No save-card option on the Checkout Page.
Customer ticks a box on the Checkout Page	ShowSaveCard=MANDATORY	A "Securely save card details for future use" checkbox they must tick before they can pay.

Don't use ShowSaveCard=YES for subscriptions. It shows the save-card checkbox as optional, which suits "save my card for next time" journeys but not payments where storing the card is a condition of the agreement.

3-D Secure challenge

When the card is being stored (AcceptCOF=YES, or the customer ticks the save-card box), TransactDirect asks the card issuer for a 3-D Secure challenge. Expect your customers to be asked to authenticate with their bank at sign-up, even if their normal purchases go through without one.

Create the payment

Create a Prepared Payment token server-side:

POST /Secure/iPayPrepare.ashx HTTP/1.1
Host: elite.monek.com
Content-Type: application/x-www-form-urlencoded

MerchantID=0000000&Amount=100&CountryCode=826&CurrencyCode=826&MessageType=ESALE_KEYED&Dispatch=NOW&ResponseAction=REDIRECT&ThreeDSAction=ACSDIRECT&AcceptCOF=YES&CAType=R&SuccessUrl=https%3A%2F%2Fwww.example.com%2Fsignup%2Fsuccess&FailureUrl=https%3A%2F%2Fwww.example.com%2Fsignup%2Ffailure&WebhookUrl=https%3A%2F%2Fwww.example.com%2Fwebhooks%2Fmonek&PaymentReference=SUB-0001-INITIAL&PreparedPaymentAction=JSON

Then redirect the customer to the Checkout Page with the returned token.

Store the result

When the payment succeeds (ResponseCode 00), check that consent was recorded: in the JSON response, card.consentToStore is true. Then store against the customer's subscription:

• CrossReference: the reference you'll charge next.
• The masked card number and expiry date, so you can show the customer which card is on file and spot cards about to expire.

Use Webhooks to confirm the result. Don't rely only on the customer's browser returning to your SuccessUrl.

Step 2: Charge the stored card

On each billing date, send a server-to-server request to the Payments API using the stored CrossReference in place of card details:

Field	Value	Purpose
MessageType	ESALE_KEYED
CrossReference	The stored reference	Sent in place of card details.
ApiKey	Your API key	Required for all CrossReference transactions.
CAType	R (Recurring)	Marks this as a payment under the recurring agreement.
COFInitiatedBy	MERCHANT	Marks this as a merchant-initiated payment with the customer not present.
ThreeDSAction	NONE	The customer isn't present, so 3-D Secure isn't performed.
IdempotencyToken	A unique value per billing attempt	Prevents double charges if your billing job retries. See Idempotency Tokens.

POST /Secure/Transact.ashx HTTP/1.1
Host: elite.monek.com
Content-Type: application/x-www-form-urlencoded

MerchantID=0000000&ApiKey=YOUR_API_KEY&Amount=3900&CountryCode=826&CurrencyCode=826&MessageType=ESALE_KEYED&Dispatch=NOW&ResponseAction=JSON&ThreeDSAction=NONE&CrossReference=240401101112457459X2R&CAType=R&COFInitiatedBy=MERCHANT&IdempotencyToken=SUB-0001-2026-12&PaymentReference=SUB-0001-2026-12

A successful charge returns ResponseCode 00 and a new crossReference in the JSON response.

Always charge the CrossReference from the most recent successful payment. Replace your stored value after every successful charge. If a charge fails, keep the previous reference.

Handling failed payments

Check the ResponseCode on every charge:

Response Code	Meaning	What to do
00	Authorised	Store the result and continue the subscription.
05	Declined	Tell the customer and ask them to update their card. See Updating a customer's card.
04	Declined, keep card	Do not retry. Ask the customer for a different card.
02	Referred	Treat as declined for recurring payments. Ask the customer to update their card.
30	Error	Check ErrorCode against Error Codes.

The error codes you're most likely to see on recurring charges are:

• 1323: stored card data couldn't be resolved for the CrossReference.
• 1381: the ApiKey is missing or invalid.
• 1501: the operation isn't allowed using a CrossReference.

Updating a customer's card

When a payment fails, or a customer wants to change card, send them to a card update page on your site. That page should start a new Checkout Page payment with AcceptCOF=YES and CAType=R, the same as Step 1. When it succeeds, replace the stored CrossReference with the new one.

The new payment can be:

• The overdue amount. This collects the failed payment and updates the card in one step.
• A zero-value verification using MessageType EVERIFY_KEYED with Amount=0. This updates the card without taking a payment. Contact Monek Support before using this option for recurring payments.

Either way, the customer will be asked to complete a 3-D Secure challenge, because a card is being stored.

Card expiry and reissue

When a customer's card expires or their bank replaces it, charges against the old card may be declined.

To avoid failed payments, check the expiry date you stored at sign-up. Ask customers to update their card before it expires.

Network tokens can help stored cards keep working when a card is reissued. Contact Monek Support to find out whether they're available on your account.

Cardholder Initiated Transactions

To let a returning customer pay with their stored card, for example a one-off purchase or upgrade, send a Payments API request from your website with the stored CrossReference and COFInitiatedBy=CARDHOLDER. Include 3-D Secure (ThreeDSAction) so the payment meets Strong Customer Authentication (SCA) requirements.

Legacy: Continuous Authority

Legacy

This method is supported for existing integrations only. New integrations should use the Credentials on File approach above.

Older integrations use the dedicated SALE_CA message type:

1. Submit the first payment as a normal transaction with the correct capture method (e.g. ESALE_KEYED) and full security details.
2. Store the CrossReference returned by a successful payment.
3. For each later payment, submit a transaction with MessageType SALE_CA, sending the stored CrossReference in place of card details.
4. After each successful payment, store the new CrossReference and use it for the next charge.

Continuous Authority by Card Token

Deprecated

Charging by CardToken is deprecated. Use CrossReference instead.