Templates and Subscriptions
Templates
Responsibility: to store data for semi- or automatic payment execution.
Template types
There are types of templates in the system:
-
transfer template
-
invoice template
1. Transfer template
DB table name: template_transfer
1.1. Create transfer template
There two options how create transfer template:
-
by operation id
-
basic way
1.1.1 Transfer Template by operation id
All required payment data are taken from the operation data
1.1.2 Transfer Template basic way
All payment data should be pasted.
reusable
– parameter shows if the template can be used in more then one subscription.
Value: true | false
paymentTool
– this section contains the required payment data.
There are two types (type
): COIN
| SMART_CARD
.
According tho this types in srcValue
and destValue
should be pasted different values:
-
for
type
COIN
it should be the coin serial numbers -
for
type
SMART_CARD
it should be the smart card numbers
1.2. Retrieve transfer templates
There are two options to obtain templates:
-
get all transfer templates
-
get all templates with filter and pagination
1.2.1 Get all transfer templates
1.2.2 Get all templates with filter and pagination
1.3. Update transfer templates
1.4. Delete transfer templates
permissons: TEMPLATES_OWNER
DELETE
/templates/transfer/{templateId}
Response:
1.5. Manual payment execution
1.5.1 Calculate payment fee by transfer template
permissons: TEMPLATES_OWNER
POST
/templates/transfer/{templateId}/calculate
Request:
Response:
1.5.2 Execute payment fee by transfer template
permissons: TEMPLATES_OWNER
POST
/templates/transfer/{templateId}/execute
Request:
Response:
2. Invoice template
DB table name: template_invoice
Subscriptions
Responsibility: to manage the regular executions of payments.
DB table name: subscription
, subscription_definition
Related entities:
Period: Templates & Subscriptions | Periods
Subscription statuses:
-
ACTIVE – subscription in progress, intermediate state
-
STOPPED – stopped subscription; intermediate state, can switch to ACTIVE
-
PROCESSED – finished subscription, terminate state
-
CANCELLED – exceptionally finished subscription, terminate state
Expiration Type (field expirationType
):
The type of ending the subscription
-
DATE – by date – regular payment is executed until the required date (field
endDate
) -
INFINITY – there are no constraints on regular payment executions
-
COUNT – by reaching required successfully executed payments (field
count
)
e.g.: stop subscription after reaching N number of successfully executed payments
Recurring Type (field type
)
-
DAILY – daily subscription execution
-
WEEKLY – weekly subscription execution
-
MONTHLY – monthly subscription execution
-
ANNUALLY – annually subscription execution
Count (field count
) – number of successfully executed payments. Default value is 1
.
Requires for expirationType = COUNT
End Date (field endDate
) – end date of subscription.
Requires for expirationType = DATE
Recurring Start Date (field recurringStartDate
) – start date of subscription
Frequency (field frequency
) – max number of execution attempts among the period (according to recurring type) after fail execution. Default value is 1
.
Template ID (field templateId
) – template ID which contains the information of payment execution
Subscriptions settings:
subscription:
remove-after-complete:
enable: false
subscription-timer:
enabled: true
schedule-expression: '0 * * ? * *' # cron expression
notification:
enable: false
Subscription APIs:
1. Create subscription task
POST /tasks
{
"type": "SUBSCRIPTION",
"name": "Subscription task 1",
"description": "Subscription task 1",
"templateId": "01987edc-0139-7277-a052-458c661f7ee1"
}
2. Create subscription schedule
POST /schedules
{
"taskId": "01987edc-61a1-7588-8d92-3590f2997b2e",
"name": "Subscription task schedule 1",
"description": "Subscription task schedule 1 - should be executed every day",
"frequency": "DAILY",
"expirationType": "END_DATE",
"startDate": "2025-01-01T00:00:00+0300",
"endDate": "2026-01-01T00:00:00+0300",
"timeZone": "UTC",
"dayOfWeek": 5,
"dayOfMonth": 15,
"hourOfDay": 18,
"minuteOfHour": 0
}
3. Activate subscription schedule
PATCH /schedules/{scheduleId}
{
"status": "ACTIVE"
}
4. Get subscription task
API operation GET /tasks
with query parameter taskType=SUBSCRIPTION
5. Update subscription task
PATCH /tasks/{taskId}
{
"type": "SUBSCRIPTION",
"name": "Subscription task 2",
"description": "Subscription task 2",
"templateId": "01987f3f-721a-7ef7-80f0-c5f820d5b16f"
}
5. Delete subscription task
API operation DELETE /tasks/{taskId}
6. Get subscription schedules
API operation GET /schedules
with query parameter taskType=SUBSCRIPTION
7. Stop subscription schedule
PATCH /schedules/{scheduleId}
{
"status": "INACTIVE"
}
8. Delete subscription schedule
API operation DELETE /schedules/{scheduleId}
Periods
Responsibility: to store next execution date for related Subscription.
DB table name: subscription_period, subscription_period_definition
Related entities: Templates & Subscriptions | Subscriptions
Period statuses:
-
SCHEDULED – when Subscription was created and a new execution date was arranged
-
FAILED – period was stoped because of exception case
-
STOPPED – when Subscription is stopped
-
PROCESSED – when the regular payment attempt was successfully finished
-
CANCELLED – when Subscription in status CANCELLED
Process period on (field processPeriodOn
) – date when related subscription should be executed.
The value of processPeriodOn
compiles
1. When Subscription is created the processPeriodOn
is the recurringStartDate
2. When Subscription is activated or arranging a next execution time the processPeriodOn
computes by Subscription frequency
value and lastProcessDate
according to the Subscription type
Calculation of the next Date for processing
OffsetDateTime lastProcessDate) {
int counter = subscription.getFrequency();
switch (subscription.getType()) {
case DAILY:
return lastProcessDate.plusDays(counter);
case WEEKLY:
return lastProcessDate.plusWeeks(counter);
case MONTHLY:
return lastProcessDate.plusMonths(counter);
case ANNUALLY:
return lastProcessDate.plusYears(counter);
default:
throw new IllegalArgumentException(“period not implemented”);
}
}