Loyalty: Validation Rules

If any of the below validations fail, the API will return an HTTP-400 error.

When a Loyalty account is created, the API will validate that:

  • The specified person exists.
  • There are no existing Loyalty accounts for the specified program that are associated with that person.
  • A site exists with a site code matching the requested home_site_code.
  • The specified customer category exists and belongs to the specified Loyalty program.

When an offer is created or updated, the API will validate that:

  • The Loyalty program and Loyalty account exist.
  • The validity period has date_to greater than or equal to date_from.
  • The discount value is greater than 0.
  • If the discount type is percentage, then discount value is not greater than 100.
  • The product or product group exists.

When an offer consumption is created, the API will validate that:

  • The Loyalty program and Loyalty account exist and are active.
  • All the offers that are to be consumed exist, and that the validity period includes the current date.
  • All the offers that are being consumed have a balance greater than or equal to the consumption value.
  • If the discount type of the offer is "percentage" then the consumption value equals the discount value of the offer.
  • All the offers that are being consumed are set to Archived = true.

When a check in is created or consumed, the API will validate that:

  • The Loyalty program and Loyalty account exist and are active.
  • The offers specified by offer code exist, belong to the specified program, and that the validity period includes the current date OR the specified pre-auth code exists, belongs to specified loyalty account code and the pre-auth code status = ‘C’.
  • If a pre-authorisation code is specified, check that the pre-authorisation exists and that the consumer of the pre-authorisation and the creator of the check in are the same Loyalty account.
  • If a check-in is created, any existing check-ins for that account will be archived.
  • If both a prepay account code and a pre-authorisation code is provided then the request is rejected.
  • The provided prepay account must exist.
  • The loyalty customers must be an active (not archived) owner or consumer of the provided prepay account.

When a check-in is consumed, the API will validate that:

  • The check-in exists and not Archived.
  • The check-in status = consumed.

When a check-in status is updated, the API will validate that:

  • If the request is to lock the check-in, then the check-in must have a status of unlocked.

When a check in is read via GET, the API will validate that:

  • The Loyalty program and Loyalty account exist.
  • The expiry date is not in the past.

When an account identifier is created or updated, the API will validate the following.

If the identifier type is "flybuys_nz" then:

  • The identifier must be 16 digits.
  • The identifier must begin with 601435.
  • The next digit must NOT be a 2.
  • The final digit must be a check digit, calculated by passing the first 15 digits through the Luhn algorithm. https://en.wikipedia.org/wiki/Luhn_algorithm. For example: 4111 1111 1111 111 produces a check digit of 1 and 6014 1234 1234 123 produces a check digit of 3.

If the identifier type is "number_plate", then the identifier must be a maximum of 6 characters and limited to A-Z and 0-9.

If the identifier type is "airpoints", then:

  • The identifier must be 16 digits.
  • The identifier must begin with 601435.
  • The next digit MUST BE a 2.
  • The final digit must be a check digit, calculated by passing the first 15 digits through the Luhn algorithm. https://en.wikipedia.org/wiki/Luhn_algorithm. For example 4111 1111 1111 111 produces a check digit of 1 and 6014 1234 1234 123 produces a check digit of 3.

 

If the identifier type is “velocity”, then the identifier must be 10 digits long, e.g. 1234567890.

The identifier does not already belong to another Loyalty account. For example:

  • GIVEN Loyalty account 12345 has a mobile_app_id identifier of “ABCDE”
  • AND a call is made to update Loyalty account 6789 to add a mobile_app_id identifier “ABCDE”
  • THEN the call to update Loyalty account 6789 will fail with an HTTP-400 error
  • GIVEN Loyalty account 12345 has a mobile_app_id identifier of “ABCDE”
  • AND a call is made to update Loyalty Account 6789 to add a number_plate identifier “ABCDE”
  • THEN the call to update Loyalty Account 6789 will succeed, because even though the identifier string is the same they are a different identifier type

For “mobile_app_id_second” use exactly the same validation rules as for mobile_app_id above.