Campaigns and rewards
Read the reward and campaign periods a customer's cards qualify for.
executeCampaignTransaction
Executes a campaign transaction for a given ShadowCardNumber. Validates the request including Channel, TrnCodeMatrixId, and Amount limits. Adjusts amount by dividing by 100. Retrieves default description from campaign system parameters if not provided. Calls DoManualFinance on CRD transaction service proxy with finance details including TranAmount, TranCurrency, TranDescription, ShadowCardNumber, ChannelType, RewardType.None, Onus network, current TranValueDate, and SystemEntry origin. Returns Utid and TrnId from the response.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
executeCampaignTransaction › Request Body
shadowCardNumberThe card the campaign transaction is posted to.
trnCodeMatrixIdThe transaction code matrix entry to post under. Must be one of the entries listed in the platform's campaign transaction code parameters; any other value is refused, whatever the transaction code matrix itself allows.
amountThe amount, in minor units. The facade divides it by 100 before doing anything else, so it must be sent as a whole number of the currency's smallest unit. It is then checked against the campaign minimum and maximum held in the platform's parameters: it must be strictly greater than the minimum and no greater than the maximum.
requestChannelThe channel the transaction is posted from. Must be a channel the platform defines; an unrecognised value resolves to the undefined channel and is refused.
Not the channel every request carries: this is one of nineteen differently-named channel fields the platform uses for other purposes, and no column behind this API stores it.
currencyDefault — The transaction currency. Left out or blank, the facade forces the local currency code 949.
No column of this name exists behind this API. currencyCode, which does, is three characters.
descriptionDefault — The transaction description. Left out or blank, the facade fills it from the campaign parameter that matches trnCodeMatrixId.
executeCampaignTransaction › Responses
Success.
amount is not the amount posted. The facade divides the value it receives by 100 before validating it and before passing it on, so the amount limits and the posted transaction are both in major units while the request is in minor ones.
Both amount limits come from a cached platform parameter rather than from the code. If that parameter is missing or unparseable the corresponding limit is not applied at all, so an unbounded amount can reach the service.
Several fields of the transaction are forced by the facade and cannot be influenced by the request: the source network is set to on-us, the reward type to none, the transaction origin to system entry, the merchant country code to a fixed value, and the value date to the moment the call is handled rather than to any date the caller supplies.
The credit transaction service also reports the daily transaction pool record it created; this facade returns only utid and trnId and discards the rest.
trnIdThe platform's identifier for the transaction row.
utidgetDebitCardForRewardByBank
Retrieves the debit card information eligible for rewards for a given customer. Accepts GetDebitCardForRewardByBankRequest with CustomerNumber and Channel. Calls _debitManagementServiceProxy.GetDebitCardForRewardByBank() and returns GetDebitCardForRewardByBankResponse containing AccountNumber, MaskedCardNumber, and ShadowCardNumber.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getDebitCardForRewardByBank › Request Body
customerNumberCustomer whose reward card is selected.
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.
getDebitCardForRewardByBank › Responses
Success.
The operation returns one card, chosen by the service rather than by the caller. Only cards in a status that is both valid and reissuable, on a product in the individual segment, are considered. Among those the service takes the first match in this order: a physical card on a product belonging to the bank's own tenant or to no tenant, then a non-physical one on such a product, then a physical card on a tenant product, then a non-physical one. Within each step the most recently created card wins.
A customer with no matching card is not an error. The operation answers 200 with accountNumber, shadowCardNumber and maskedCardNumber all null, which is also what an unknown customer number produces.
accountNumberThe account at the bank's core banking system that the card draws on. It must already exist, belong to the card's customer, and be neither shared nor a foreign-currency account.
maskedCardNumberThe card number with its middle digits masked, as the platform stores it. It is a display form, not a key: operations take the shadow number.
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.