Overview
  • Updated on 17 Jun 2020
  • 5 minutes to read
  • Contributors
  • Print
  • Dark
    Light

Overview

  • Print
  • Dark
    Light

1. Clearance Request /ClearanceRQ/

The request to start the clearance for the amount agreed during the ordering process. This message is always sent by Offer Responsible Airline (ORA) to the settlement manager. The ClearanceRQ message allows for sending ‘N’ number of clearances at once, where ‘N’ can be bigger than or equal to one (N ≥ 1). Each Clearance in the ClearanceRQ message is uniquely identified with its “ClearanceID”. The “ClearanceID” has maximum 15 characters that are defined as follows:

  • First seven (7) positions are numeric only, where the first four digits represent the year (such as 2019) and the next 3 digits represent the accounting code of the carrier (such as 954)
  • Last 8 positions are alphanumeric and represent unique identifier generated by the carrier.

As an option the carrier can include one identifier that is of significance only to carrier’s own operations. This identifier is the “AirlineRefID” and it is alphanumeric with maximum 15 characters.

The carrier sending the ClearanceRQ message can decide how the individual Clearances will be processed by the Settlement Manager:

  • Accept the Clearances that pass validation and reject the ones that do not
  • Reject all Clearances as long as one Clearance fails validation

ORA communicates its choice to the Settlement Manager by setting the “Reject Every Clearance Indicator” to either ‘TRUE’ or ‘FALSE’. When the value of the “Reject Every Clearance Indicator” is set to ‘TRUE’ then all Clearances must be rejected as long as only one fails validation. If “Reject Every Clearance Indicator” is set to ‘FALSE’ or is omitted, then the settlement manager will reject only the clearances that do not pass validation. The fact that the ClearanceRQ caters for this option does not mean that it must be provided by the Settlement Manager.

In addition, ORA must identify the governance for each Clearance and to communicate it to the Settlement Manager using the Clearance Process Rule. The Settlement Manager defines the rules their respective codes and their meaning. The codes are listed in Annex B under code list identifier “CPRC – Clearance Process Rule Code”.

The ClearanceRQ message must be sent not later than the next day after the payment for the sale has been confirmed. For transactions paid in cash this is when ORA receives payment information with an amount. For transactions paid using EasyPay this is when the Approval Code from the EasyPay vendor has been received. The Payment Commitment Date indicates when payment is considered successful and the sale confirmed by ORA.

In case of discrepancies between the definitions given in the xsd released as part of the standard and the definitions in this implementation guide for the same concept or data element it is the definition in the xsd that is valid. XML messages must be validated with the corresponding xsd.

a) Sample ClearanceRQ XML

Please see IATA_PaymentClearanceRQ.xml

2. Clearance Response /ClearanceRS/

this is the response sent by the Settlement Manager back to ORA as an acknowledgement of the Clearance Request. It delivers either the errors that prevented message processing and response to be generated, or a response. This response provides information of the settlement process status and the settlement and remittance dates. The “ClearanceRS” is sent in response to the “ClearanceRQ” message providing these additional data for each Clearance:

  • Remittance Date – irrespective if it was or wasn’t provided in the received “ClearanceRQ” message.
  • Settlement Date – based on the date the Clearance is received by the Settlement Manager and in correspondence to the settlement date from the “SwO Schedule”.
  • Clearance Status Code – defines the status of the Clearance and can be one of the codes listed in Annex B under code list identifier “CSTC – Clearance Status Code”.
  • Clearance Failure Reason Code – provides the reason why a Clearance was rejected during validation and can be one of the codes listed in Annex B under code list identifier “CFRC – Clearance Failure Reason Code”.

The ClearanceRS message can include ‘N’ number of clearances at once. ‘N’ must equal to the number of clearances sent in the ClearanceRQ message to which this ClearanceRS message is the response. The Clearances in the ClearanceRS message must be the same Clearances, identified by their unique identifiers, sent in the corresponding ClearanceRQ. The ClearanceRS message will have the exact same structure as the ClearanceRQ message. Each individual Clearance in the ClearanceRS message will have value for the Clearance Status Code data element of either “Accepted” or “Rejected” and the validation failures clearly identified in the Clearance Failure Reason Code.
In case of discrepancies between the definitions given in the xsd released as part of the standard and the definitions in this implementation guide for the same concept or data element it is the definition in the xsd that is valid. XML messages must be validated with the corresponding xsd.

a) Sample ClearanceRS XML

Please see IATA_PaymentClearanceRS.xml

3. Clearance Notification /ClearanceNotif/

this is unsolicited notification that provides information about upcoming remittance (date of remittance, amount, form of payment, remit ID, currency etc) or upcoming settlement (date of settlement, amount, currency, etc). The party receiving this message can use it to confirm that clearance for already agreed payment has been initiated. The ClearanceNotif message can include ‘N’ number of clearances at once. The party receiving the ClearanceNotif message can choose, in its initial set up when joining the SwO Platform, if N should equal to 1 (N=1) or be bigger than one 1(N > 1). If the Seller chooses to receive ClearanceNotif message with more than one Clearance then the same ClearanceNotif could include Clearances from multiple carriers. The Settlement Manager will send all ClearanceNotif messages respecting the receiving party set up in the Settlement Platform.

In case of discrepancies between the definitions given in the xsd released as part of the standard and the definitions in this implementation guide for the same concept or data element it is the definition in the xsd that is valid. XML messages must be validated with the corresponding xsd.

a) Sample ClearanceNotif XML

(the party receiving this message has chosen to receive multiple clearances in one ClearanceNotif message. If the party receiving the ClearanceNotif had chosen to receive one Clearance per ClearanceNotif message, then the Settlement manager would have created two ClearanceNotif messages – one for each Clearance). Please see IATA_PaymentClearanceNotif.xml