Operation limits
Cap what a card may do per transaction, per day, per week and per month, by channel and operation type.
getCardLimitationParameterData
Gets card limitation parameter data for a prepaid card.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getCardLimitationParameterData › Request Body
shadowCardNumberThe platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.
getCardLimitationParameterData › Responses
Success
getCustomerOperationLimit
Gets the operation limit set for a customer.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getCustomerOperationLimit › Request Body
channelThree-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.
customerNumberThe customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.
getCustomerOperationLimit › Responses
Success
The limit rows to set.
getCardOperationLimit
Gets the operation limit set for a prepaid card.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getCardOperationLimit › Request Body
channelThree-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.
cardRefNumberThe card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.
getCardOperationLimit › Responses
Success
The limit rows to set.
setCustomerOperationLimit
Sets an operation limit on a prepaid customer.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
setCustomerOperationLimit › Request Body
channelThree-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.
customerNumberThe customer whose limits are written. These limits are not prepaid's. This operation forwards to the customer service, not to a prepaid service, so a customer-level operation limit written here is the same row the credit and debit APIs write — one customer, one set of customer limits, whichever programme wrote it.
Required in practice — The limits to write. Not checked here; an absent list reaches the customer service as nothing to do.
setCustomerOperationLimit › Responses
Success.
Each entry is answered separately in listOfResult, with its own success, its own errors and the actionType the row resolved to — Insert, Update, Delete or None. A 200 does not mean every entry was applied, and None means the row was read and changed nothing.
One entry per item the request asked about.
setCardOperationLimit
Sets an operation limit on a prepaid card.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
setCardOperationLimit › Request Body
channelThree-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.
cardRefNumberRequired in practice — The card whose limits are written. Not validated here — unlike credit and debit, where the facade checks it, the prepaid facade maps and forwards with no check at all.
Required in practice — The limits to write. An absent or empty list is not refused here; it reaches the lifecycle service as nothing to do.
setCardOperationLimit › Responses
Success.
Each entry is answered separately in listOfResult, with its own success, its own errors and the actionType the row resolved to — Insert, Update, Delete or None. A 200 does not mean every entry was applied, and None means the row was read and changed nothing.
cardType in the response is not an answer. The facade writes P onto every returned row, so it says this is the prepaid API rather than anything about the card or the row.
One entry per item the request asked about.
removeCustomerOperationLimit
Removes a specific operation limit from a prepaid customer.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
removeCustomerOperationLimit › Request Body
channelThree-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.
customerNumberThe customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.
The limit rows to read, by their keys.
removeCustomerOperationLimit › Responses
Success
One entry per item the request asked about.
removeCardOperationLimit
Removes a specific operation limit from a prepaid card.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
removeCardOperationLimit › Request Body
channelThree-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.
cardRefNumberRequired in practice — The card whose limit rows are removed. Not validated here.
Required in practice — The rows to remove. Each entry is one operationLimitRecordId and nothing else — the facade maps that single field and discards the rest of the key. So a row is removed by the id setCardOperationLimit and getCardOperationLimit hand back, never by describing its channel, network and event again.
removeCardOperationLimit › Responses
Success.
Each entry is answered separately in listOfResult, with its own success, its own errors and the actionType the row resolved to — Insert, Update, Delete or None. A 200 does not mean every entry was applied, and None means the row was read and changed nothing.
Each answered row echoes the operationLimitRecordId it was about, which is how a result is matched back to a request entry.
One entry per item the request asked about.
getCustomerLimitationParameterData
Gets customer limitation parameter data for prepaid operations.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getCustomerLimitationParameterData › Request Body
customerNumberThe customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.
getCustomerLimitationParameterData › Responses
Success