1.1.8. Recurring Payments service¶
Recurring (also Recurrent) payments transactions is a type of bank payments, where charges are applied to a cardholder in predetermined intervals for services or goods of an ongoing nature (memberships, subscriptions, loan payments). Prior to the charges, card must be registered in system. Charges will be made according to balancing set on project level.
Single operations¶
Recurring Payments API¶
Create Recurring Payments¶
Create Recurring Payments API URLs¶
Create Recurring Payments API call is initiated through HTTPS POST request by using URLs and the parameters specified below. See OAuth RSA-SHA256 for authentication.
Create Recurring Payments Request Parameters¶
Note
Create Recurring Payment request parameters | Length/Type | Source/Destination card type | Description | Necessity |
---|---|---|---|---|
rp_card_type | none | none | SRC - source card. DST - destination card. | Mandatory |
client-orderid | 128/String | SRC/DST | Merchant order ID | Mandatory |
Merchant login | 20/String | SRC/DST | Merchant’s login name | Mandatory |
Endpoint | 10/Numeric | SRC/DST | Endpoint ID | Mandatory |
order_desc | 65K/String | SRC/DST | Description of Recurring payment | Mandatory |
credit-card-number | 20/Numeric | SRC/DST | Clients credit card number | Mandatory |
currency | 3/String | SRC/DST | Currency type | Mandatory |
country | 2/String | Not supported for DST | Clients country. | Mandatory |
city | 128/String | Not supported for DST | Clients city. | Mandatory |
zip-code | 10/String | Not supported for DST | Clients zip-code. | Mandatory |
address1 | 256/String | Not supported for DST | Clients address. | Mandatory |
first-name | 128/String | Not supported for DST | Clients first name. | Mandatory |
last-name | 128/String | Not supported for DST | Clients last name. | Mandatory |
customer-ip | 45/String | SRC/DST | Clients IP address | Mandatory |
128/String | Not supported for DST | Clients email. | Mandatory | |
card-printed-name | 128/String | Mandatory for SRC, optional for DST | Clients card printed name. | Mandatory/Optional |
expire-month | 2/Numeric | Mandatory for SRC, optional for DST | Clients card expire month. | Mandatory/Optional |
expire-year | 4/Numeric | Mandatory for SRC, optional for DST | Clients card expire year. | Mandatory/Optional |
ssn | 32/String | Not supported for DST | Social security number field. | Optional |
birthday | 8/Numeric, YYYYMMDD | Not supported for DST | Clients birthday date. | Optional |
phone | 128/String | Not supported for DST | Clients phone number. | Optional |
state | 2-3/String | Not supported for DST | Clients state. | Optional |
period | 32/String | Not supported for DST | Period can be day, week and month. In case if daily is chosen, client will be charged every day. If week - every 7 days. If monthly is chosen, client will be charged on the same date of the month, from the starting date, no matter how many days there are in a month. | Optional |
interval | int | Not supported for DST | Interval is a multiplier applied to the period. For example, if interval of 2 and period ‘Daily’ is selected, client will be charged once every 2 days. | Optional |
start-date | 8/Numeric, YYYYMMDD | SRC/DST | Date, when first charge is scheduled. If start date is set as a current date and type is set as auto, first charge will be made today | Optional |
finish-date | 8/Numeric, YYYYMMDD | SRC/DST | Date, when the client will be charged last time | Optional |
max-repeats-number | int | SRC/DST | Index of recurring transaction, first charge will hold the index of 0. Current repeats number increases even if a charge was unsuccessful. When current repeats number reaches max repeats number, Recurring payment goes into stop status and client is charged no more. If a charge was made automatically, no additional charges will be made(unless done manually), even if a recurring payment is stopped and rescheduled again | Optional |
amount | 255/String | SRC/DST | Amount of currency must be the same as currency on the project assigned. Upon reaching finish date, Recurring payment will go into stop status | Optional |
amount-from | 255/String | SRC/DST | If amount from+amount to is chosen, every charge will be of random amount between these two numbers | Optional |
amount-to | 255/String | SRC/DST | If amount from+amount to is chosen, every charge will be of random amount between these two numbers | Optional |
amount-sequence | 255/String | SRC/DST | If amount sequence is chosen, client will be charged amounts from this list. Example of setting up amount sequence: 10.5, 24.6, 32.0. If repeats number is higher than amount sequence number of elements, every new charge will be with last amount in amount sequence. In order for charges to begin from the first amount in the chain, current repeats number must be set as 0 | Optional |
purpose | 128/String | Not supported for DST | Purpose of transaction. | Optional |
notify_url | 1024/String | SRC/DST | Notify url field.:code:server_callback_url parameter can also be used. For more information please see _merchants_callbacks | Optional |
Create Recurring Payment Request Example¶
address1=rpdDowning st., 10
amount=1.07
birthday=11.02.1996
card_printed_name=rpdA B
city=London
client_orderid=6685d0c4-c9e7-452d-bdcd-a41f2b341df5
country=GB
credit_card_number=4444555566661111
currency=USD
customer_ip=127.0.0.1
email=rpdG@example.com
expire_month=1
expire_year=2040
first_name=rpdA
last_name=rpdB
notify_url=http://localhost/rpdNotifyUrl
order_desc=rpdDsc
phone=+19834384
purpose=rpdPurpose
rp_card_type=SRC
server_callback_url=http://localhost/rpdServerCallbackUrl
ssn=rpdSsn
state=ABC
zip_code=898
Create Recurring Payment Response Parameters¶
Note
Create Recurring Payment Response Parameters | Description |
---|---|
type | The type of response. Example: create-recurring-payment-response |
recurring-payment-id | Recurring ID assigned to the order by Mobilum |
status | See Status List for details |
serial-number | Unique number assigned by Mobilum server to particular request from the Merchant |
Create Recurring Payments Response Example¶
recurring-payment-id=421
serial-number=00000000-0000-0000-0000-0000000005f6
status=approved
type=create-recurring-payment-response
Create Recurring Payments Debug¶
Debug form
Normalized parameters string to sign, according to OAuth 1.0a rules |
---|
POST body parameters to submit |
---|
OAuth 1.0a headers to submit. |
---|
HEX Encoded Signature |
---|
Base64 Encoded Signature |
---|
|
Process Recurring Payments (Source card only)¶
The End point ID is an entry point for incoming Merchant’s transactions. Create Recurring Payments API call is initiated through HTTPS POST request by using URLs and the parameters specified below. See OAuth RSA-SHA256 for authentication.
Recurring Payment Process Request Parameters¶
Note
Create Recurring Payment request parameters | Length/Type | Description | Necessity |
---|---|---|---|
client-orderid | 128/String | Merchant order ID | Mandatory |
recurring-payment-id | long | Recurring ID assigned to the order by Mobilum | Mandatory |
amount | 255/String | Amount of currency must be the same as currency on the project assigned. Upon reaching finish date, Recurring payment will go into stop status | Mandatory |
Process Recurring Payment Response Parameters¶
Note
Process Recurring Payment Response Parameters | Description |
---|---|
type | The type of response. Example: process-recurring-payment-response |
status | See Status List for details |
serial-number | Unique number assigned by Mobilum server to particular request from the Merchant |
Process Recurring Payments Debug¶
Process recurring payment debugger can be used to initiate a manual charge from a customer. Manual charges made this way do not interact with automatic charges in any way and they don`t increase any counters.
To reproduce your API call, input all of the data from your original request, including the authentication tokens. Don’t forget to set the nonce and timestamp to the values you used. An OAuth signed URL should match regardless of the generating library. If the signatures differ, you know there is a bug in your OAuth signature code. Due to current PCI DSS restrictions only OAuth 1.0a RSA-SHA256 signature is allowed. Other signature methods are restricted. So to send command to the server your request should be: sent as POST, contains OAuth 1.0a headers, signed with RSA-SHA256.
Generate Public and Private key pair
You need only private and public key to authorize your transaction. To generate it please got to https://www.openssl.org/ download latest version of openssl and run following commands:
openssl genpkey -algorithm RSA -out test-private-2048.pem -pkeyopt rsa_keygen_bits:2048
openssl rsa -pubout -in test-private-2048.pem -out test-public-2048.pem
Share your Private key with no one, you should be the only person to know it. Your Public key, on the contrary, should be sent to your manager, so he can register it in the system. Use different keys for production and for testing purposes to avoid its compromisation.
For using this demo you need private key in PKCS#8 container.
Debug form
Normalized parameters string to sign, according to OAuth 1.0a rules |
---|
POST body parameters to submit |
---|
OAuth 1.0a headers to submit. |
---|
HEX Encoded Signature |
---|
Base64 Encoded Signature |
---|
|
|
Recurring payment update¶
Create Recurring Payments API call is initiated through HTTPS POST request by using URLs and the parameters specified below. See OAuth RSA-SHA256 for authentication.
Update Recurring Payment Request Parameters¶
Note
Create Recurring Payment request parameters | Length/Type | Source/Destination card | Description | Necessity |
---|---|---|---|---|
client-orderid | 128/String | SRC/DST | Merchant order ID | Mandatory |
recurring-payment-id | long | SRC/DST | Recurring ID assigned to the order by Mobilum | Mandatory |
Merchant login | 20/String | SRC/DST | Merchant’s login name | Mandatory |
Endpoint | 10/Numeric | SRC/DST | Endpoint ID | Mandatory |
order_desc | 65K/String | SRC/DST | Description of Recurring payment | Mandatory |
type | auto/manual | SRC/DST | Recurring payments can be set as auto and manual. If set as auto, charges will be applied automatically in accordance with this schedule. If set as manual, client can be charged only manually with the help of Recur transaction/API call | Optional |
credit-card-number | 20/Numeric | SRC/DST | Clients credit card number | Optional |
card-printed-name | 128/String | SRC/DST | Clients card printed name | Optional |
expire-month | 2/Numeric | SRC/DST | Clients card expire month | Optional |
expire-year | 4/Numeric | SRC/DST | Clients card expire year | Optional |
first-name | 128/String | Not supported for DST | Clients first name. | Optional |
last-name | 128/String | Not supported for DST | Clients last name. | Optional |
birthday | 8/Numeric, YYYYMMDD | Not supported for DST | Clients birthday date. | Optional |
customer-ip | 45/String | SRC/DST | Clients IP address | Optional |
ssn | 32/String | Not supported for DST | Social security number field. | Optional |
country | 2/String | Not supported for DST | Clients country. | Optional |
state | 2-3/String | Not supported for DST | Clients state. | Optional |
city | 128/String | Not supported for DST | Clients city. | Optional |
zip-code | 10/String | Not supported for DST | Clients zip-code. | Optional |
address1 | 256/String | Not supported for DST | Clients address. | Optional |
phone | 128/String | Not supported for DST | Clients phone number. | Optional |
128/String | Not supported for DST | Clients email. | Optional | |
period | 32/String | Not supported for DST | Period can be day, week and month. In case if daily is chosen, client will be charged every day. If week - every 7 days. If monthly is chosen, client will be charged on the same date of the month, from the starting date, no matter how many days there are in a month. | Optional |
interval | int | Not supported for DST | Interval is a multiplier applied to the period. For example, if interval of 2 and period ‘Daily’ is selected, client will be charged once every 2 days. | Optional |
start-date | 8/Numeric, YYYYMMDD | SRC/DST | Date, when first charge is scheduled. If start date is set as a current date and type is set as auto, first charge will be made today | Optional |
finish-date | 8/Numeric, YYYYMMDD | SRC/DST | Date, when the client will be charged last time | Optional |
max-repeats-number | int | SRC/DST | Index of recurring transaction, first charge will hold the index of 0. Current repeats number increases even if a charge was unsuccessful. When current repeats number reaches max repeats number, Recurring payment goes into stop status and client is charged no more. If a charge was made automatically, no additional charges will be made(unless done manually), even if a recurring payment is stopped and rescheduled again | Optional |
amount | 255/String | SRC/DST | Amount of currency must be the same as currency on the project assigned. Upon reaching finish date, Recurring payment will go into stop status | Optional |
amount-from | 255/String | SRC/DST | If amount from+amount to is chosen, every charge will be of random amount between these two numbers | Optional |
amount-to | 255/String | SRC/DST | If amount from+amount to is chosen, every charge will be of random amount between these two numbers | Optional |
amount-sequence | 255/String | SRC/DST | If amount sequence is chosen, client will be charged amounts from this list. Example of setting up amount sequence: 10.5, 24.6, 32.0. If repeats number is higher than amount sequence number of elements, every new charge will be with last amount in amount sequence. In order for charges to begin from the first amount in the chain, current repeats number must be set as 0 | Optional |
purpose | 128/String | Not supported for DST | Purpose of transaction. | Optional |
notify_url | 1024/String | SRC/DST | Notify url field. server_callback_url parameter can also be used. For more information please see merchants_callbacks | Optional |
Update Recurring Payment Response Parameters¶
Note
Update Recurring Payment Response Parameters | Description |
---|---|
type | The type of response. Example: update-recurring-payment-response |
status | See Status List for details |
serial-number | Unique number assigned by Mobilum server to particular request from the Merchant |
Update Recurring Payment Request Example¶
address1=Downing st., 10
amount=2.08
birthday=12.03.1996
card_printed_name=A B
city=London
client_orderid=9f37992f-3b4d-476a-960f-536a953ba7bf
country=GB
credit_card_number=5555666644441111
email=g@example.com
expire_month=2
expire_year=2042
first_name=A
last_name=B
order_desc=dsc2
phone=+19834384
purpose=aPurpose
recurring_payment_id=2
server_callback_url=http://localhost/aServerCallbackUrl
ssn=aSsn
state=ABC
zip_code=898
Update Recurring Payment Response Example¶
serial-number=00000000-0000-0000-0000-000000000005
status=approved
type=update-recurring-payment-response
Update Recurring Payments Debug¶
Generate Public and Private key pair
You need only private and public key to authorize your transaction. To generate it please got to https://www.openssl.org/ download latest version of openssl and run following commands:
openssl genpkey -algorithm RSA -out test-private-2048.pem -pkeyopt rsa_keygen_bits:2048
openssl rsa -pubout -in test-private-2048.pem -out test-public-2048.pem
Share your Private key with no one, you should be the only person to know it. Your Public key, on the contrary, should be sent to your manager, so he can register it in the system. Use different keys for production and for testing purposes to avoid its compromisation.
For using this demo you need private key in PKCS#8 container.
Debug form
Normalized parameters string to sign, according to OAuth 1.0a rules |
---|
POST body parameters to submit |
---|
OAuth 1.0a headers to submit. |
---|
HEX Encoded Signature |
---|
Base64 Encoded Signature |
---|
|
Batch operations¶
Recurring payments are added and updated in the system in batches. In order to do it, navigate to “Tools - Batch operations”.
Note
To add or update recurring payments, download an example presented, fill in your clients, following an example, and upload it.
Warning
Microsoft Excel can display .csv files wrong, for better user experience a different office suite, for instance, LibreOffice. Only “amount” OR “amount from” + “amount to” OR “amount sequence” should be filled in.
Update of recurring payments is done on “Update recurring payments” page in the same way. Recurring transactions will be updated based on “Recurring payment ID” parameter.
Recurring Payments Batch API¶
Create Recurring Payments API call is initiated through HTTPS POST request by using URLs and the parameters specified below. See OAuth RSA-SHA256 for authentication.
Note
Add Document request parameters | Length/Type | Description | Necessity |
---|---|---|---|
client-orderid | 128/String | Merchant order ID | Mandatory |
Merchant login | 20/String | Merchant’s login name | Mandatory |
Endpoint | 10/Numeric | Endpoint ID | Mandatory |
payment-description | 65K/String | Description of Recurring payment | Mandatory |
first-name | 128/String | Clients first name | Mandatory |
last-name | 128/String | Clients last name | Mandatory |
customer-ip | 45/String | Clients IP address | Mandatory |
country | 2/String | Clients country | Mandatory |
address1 | 256/String | Clients address | Mandatory |
zip-code | 10/String | Clients zip-code | Mandatory |
phone | 128/String | Clients phone number | Mandatory |
128/String | Clients email | Mandatory | |
currency | 3/String | Currency type | Mandatory |
card-printed-name | 128/String | Clients card printed name | Mandatory |
credit-card-number | 20/Numeric | Clients credit card number | Mandatory |
expire-month | 2/Numeric | Clients card expire month | Mandatory |
expire-year | 4/Numeric | Clients card expire year | Mandatory |
notify-url | 1024/String | Notify url field | Mandatory |
birthday | 8/Numeric, YYYYMMDD | Clients birthday date | Optional |
state | 2-3/String | Clients state | Optional |
purpose | 128/String | Purpose of transaction | Optional |
ssn | 32/String | Social security number field | Optional |
cvv2 | 3-4/Numeric | Clients cvv2 code | Optional |
period | 32/String | Period can be day, week and month. In case if daily is chosen, client will be charged every day. If week - every 7 days. If monthly is chosen, client will be charged on the same date of the month, from the starting date, no matter how many days there are in a month | Optional |
interval | int | Interval is a multiplier applied to the period. For example, if interval of 2 and period ‘Daily’ is selected, client will be charged once every 2 days | Optional |
start-date | 8/Numeric, YYYYMMDD | Date, when first charge is scheduled. If start date is set as a current date and type is set as auto, first charge will be made today | Optional |
finish-date | 8/Numeric, YYYYMMDD | Date, when the client will be charged last time | Optional |
max-repeats-number | int | Index of recurring transaction, first charge will hold the index of 0. Current repeats number increases even if a charge was unsuccessful. When current repeats number reaches max repeats number, Recurring payment goes into stop status and client is charged no more. If a charge was made automatically, no additional charges will be made(unless done manually), even if a recurring payment is stopped and rescheduled again | Optional |
amount | 255/String | Amount of currency must be the same as currency on the project assigned. Upon reaching finish date, Recurring payment will go into stop status | Optional |
amount-from | 255/String | If amount from+amount to is chosen, every charge will be of random amount between these two numbers | Optional |
amount-to | 255/String | If amount from+amount to is chosen, every charge will be of random amount between these two numbers | Optional |
amount-sequence | 255/String | If amount sequence is chosen, client will be charged amounts from this list. Example of setting up amount sequence: 10.5, 24.6, 32.0. If repeats number is higher than amount sequence number of elements, every new charge will be with last amount in amount sequence. In order for charges to begin from the first amount in the chain, current repeats number must be set as 0 | Optional |
The End point ID is an entry point for incoming Merchant’s transactions.
Note
Update request parameters | Length/Type | Description | Necessity |
---|---|---|---|
recurring-payment-id | long | ID assigned by Mobilum | Mandatory |
type | auto/manual | Recurring payments can be set as auto and manual. If set as auto, charges will be applied automatically in accordance with this schedule. If set as manual, client can be charged only manually with the help of Recur transaction/API call | Mandatory |
Merchant login | 20/String | Merchant’s login name | Mandatory |
Endpoint | 40/Numeric | Endpoint ID | Mandatory |
client-orderid | 128/String | Merchant order ID | Optional |
payment-description | 65K/String | Description of Recurring payment | Optional |
first-name | 128/String | Clients first name | Optional |
last-name | 128/String | Clients last name | Optional |
address1 | 256/String | Clients address | Optional |
birthday | 8/Numeric, YYYYMMDD | Clients birthday date | Optional |
zip-code | 10/String | Clients zip-code | Optional |
country | 2/String | Clients country | Optional |
state | 2-3/String | Clients state | Optional |
phone | 128/String | Clients phone number | Optional |
128/String | Clients email | Optional | |
ssn | 32/String | Social security number field | Optional |
period | 32/String | Period can be day, week and month. In case if daily is chosen, client will be charged every day. If week - every 7 days. If monthly is chosen, client will be charged on the same date of the month, from the starting date, no matter how many days there are in a month | Optional |
interval | int | Interval is a multiplier applied to the period. For example, if interval of 2 and period ‘Daily’ is selected, client will be charged once every 2 days | Optional |
start-date | 8/Numeric, YYYYMMDD | Date, when first charge is scheduled. If start date is set as a current date and type is set as auto, first charge will be made today | Optional |
finish-date | 8/Numeric, YYYYMMDD | Date, when the client will be charged last time | Optional |
max-repeats-number | int | Index of recurring transaction, first charge will hold the index of 0. Current repeats number increases even if a charge was unsuccessful. When current repeats number reaches max repeats number, Recurring payment goes into stop status and client is charged no more. If a charge was made automatically, no additional charges will be made(unless done manually), even if a recurring payment is stopped and rescheduled again | Optional |
amount | 255/String | Amount of currency must be the same as currency on the project assigned. Upon reaching finish date, Recurring payment will go into stop status | Optional |
amount-from | 255/String | Amount of currency must be the same as currency on the project assigned. Upon reaching finish date, Recurring payment will go into stop status | Optional |
amount-to | 255/String | If amount from+amount to is chosen, every charge will be of random amount between these two numbers | Optional |
amount-sequence | 255/String | If amount sequence is chosen, client will be charged amounts from this list. Example of setting up amount sequence: 10.5, 24.6, 32.0. If repeats number is higher than amount sequence number of elements, every new charge will be with last amount in amount sequence. In order for charges to begin from the first amount in the chain, current repeats number must be set as 0 | Optional |
currency | 3/String | Currency type | Optional |
card-printed-name | 128/String | Clients card printed name | Optional |
credit-card-number | 20/Numeric | Clients credit card number | Optional |
expire-month | 2/Numeric | Clients card expire month | Optional |
expire-year | 255/String | Clients card expire year | Optional |
cvv2 | 3-4/Numeric | Clients cvv2 code | Optional |
purpose | 128/String | Purpose of transaction | Optional |
notify-url | 1024/String | Notify url field | Optional |
The End point ID is an entry point for incoming Merchant’s transactions.
Note
Recurring payment request parameters | Length/Type | Description | Necessity |
---|---|---|---|
recurring-payment-id | long | ID assigned by Mobilum | Mandatory |
Merchant login | 20/String | Merchant’s login name | Mandatory |
Endpoint | 40/String | Endpoint ID | Mandatory |
payment-description | 65K/String | Description of Recurring payment | Mandatory |
amount | 255/String | Amount of currency must be the same as currency on the project assigned. Upon reaching finish date, Recurring payment will go into stop status | Mandatory |
currency | 3/String | Currency type | Mandatory |
client-orderid | 128/String | Merchant order ID | Optional |
first-name | 128/String | Clients first name | Optional |
last-name | 128/String | Clients last name | Optional |
birthday | 8/Numeric, YYYYMMDD | Clients birthday date | Optional |
address1 | 256/String | Clients address | Optional |
zip-code | 10/String | Clients zip-code | Optional |
country | 2/String | Clients country | Optional |
state | 2-3/String | Clients state | Optional |
phone | 128/String | Clients phone number | Optional |
128/String | Clients email | Optional | |
ssn | 32/String | Social security number field | Optional |
purpose | 128/String | Purpose of transaction | Optional |
notify-url | 1024/String | Notify url field | Optional |
Recurring payments page overview¶
Once recurring payments are registered in the system, you can view full list of them in “Orders - Recurring payments”
Recurrence details section presents general information about the transaction. Recurrence ID can be found here, which is used for updating recurring payments.
Customer details section shows general information about client (city, e-mail, etc). Note, that this info can be changed for further Recurring charges.
Actions history page shows history of changes in this Recurring payment (schedule changes, status changes, manual charges), data and status of these actions.
Recurring Schedule Parameters | Description |
---|---|
Type | Recurring payments can be set as auto and manual. If set as auto, charges will be applied automatically in accordance with this schedule. If set as manual, client can be charged only manually with the help of Recur transaction/API call |
Period | Period can be daily, weekly and monthly. In case if daily is chosen, client will be charged every day. If weekly - every 7 days. If monthly is chosen, client will be charged on the same date of the month, from the starting date, no matter how many days there are in a month |
Interval | Interval is a multiplier applied to the period. For example, if interval of 2 and period ‘Daily’ is selected, client will be charged once every 2 days |
Start date | Date, when first charge is scheduled. If start date is set as a current date and type is set as auto, first charge will be made today |
Finish date | Date, when the client will be charged last time |
Max & current repeats number | Index of recurring transaction, first charge will hold the index of 0. Current repeats number increases even if a charge was unsuccessful. When current repeats number reaches max repeats number, Recurring payment goes into stop status and client is charged no more. If a charge was made automatically, no additional charges will be made(unless done manually), even if a recurring payment is stopped and rescheduled again |
Currency | Currency of recurring payments, must be the same as currency on the project assigned. Upon reaching finish date, Recurring payment will go into stop status |
Exact amount | If exact amount is chosen, every charge will be of that amount |
Amount from/amount to | If amount from+amount to is chosen, every charge will be of random amount between these two numbers |
Amount sequence | If amount sequence is chosen, client will be charged amounts from this list. Example of setting up amount sequence: 10.5, 24.6, 32.0. If repeats number is higher than amount sequence number of elements, every new charge will be with last amount in amount sequence. In order for charges to begin from the first amount in the chain, current repeats number must be set as 0 |
Native type is reserved for future use and is not yet functional.
Current status can be “scheduled” or “stopped” and represents if this recurring transaction is turned on or off.
Processing status can hold the following values:
- idle - recurring payment is currently not queued to be processed
- queued - recurring payment is in queue to be processed.
- dequeued - recurring payment is taken out of the processing queue to be executed.
- processing - recurring payment is currently being processed
- failed - transaction has not received a final status and needs to be finalized.
Next fire date is a date when client will be charged next time.
Change card data action allows you to change data of the card to be charged.
Recur transaction action is a manual charge of a client. It won`t increase repeats number counter. Manual charges made this way do not interact with automatic charges in any way.
Suspend action lets you stop future charges on current recurring transaction.