Debt payment

Take a payment against card debt, check a card is eligible to be paid down, and cancel a payment that should not have run.

Operations8DomainBilling and statementsStatedocumentedAPIs3

Where this is used

Implemented on 2 programmes. A capability is one business idea, built once per card programme, so these are the programmes it applies to.

Journeys that walk through it

How this behaves

Which transaction code a payment is written under is searched for

It is not a field you set. The service resolves it from the channel payment matrix in four steps, and a value it does not recognise does not fail — it falls through to the next one.

  1. A resource code of 0, 1, 2 or 3 selects the row for that code.
  2. Anything else: the row whose resource code is empty.
  3. No such row: the channel's first row.
  4. No rows at all: a built-in default.
The channel is padded before it is matched.

It is left-padded with zeros to three characters, so 1 is looked up as 001. Send the code as the catalogue spells it and this never arises — the codes are in Channels.

The notification is narrower than it looks

A payment SMS is sent only when the channel is the batch channel. On every other channel the notification call is not made at all — that is a condition in the code, not a missing configuration.

Even there it is wrapped: a failed send is logged as a warning and the payment stands. A missing SMS never means a missing payment.

If the shadow card number is omitted the clear card number is resolved to one through the customer service first, so either identifier works.