Pair Incoming Payment
This chapter describes the process of pairing incoming payments to registered documents in OCS.io. The process involves matching attributes from the incoming payment to attributes in the registered documents.
The process is divided into two main parts: Promise to Pay and Non-Promise to Pay.
In the Promise to Pay section, the system first checks if the incoming payment is a promise to pay by matching the name of the EDR file with the account identification for MERCH or COMG. If it is a promise to pay, the system proceeds with a series of steps to check if the incoming payment matches the promised payment.
In the Non-Promise to Pay section, if the incoming payment is not a promise to pay, the system identifies the payment according to a defined scenario. The system checks various combinations of payment references and document numbers to find a match.
If the incoming payment does not match any created document or promised payment, it is considered as an unidentified payment and the process ends. After the pairing process, the payment is registered and if there are no errors, the result is set to 'ok'. Finally, the payment is published to Kafka. If the payment was identified as a 'Promise to Pay', it is also published to Kafka. If the payment was assigned to a document, a notification of payment received is sent.
Promise to Pay
The system first checks if the incoming payment is a Promise to Pay. This is determined by matching the name of the EDR file with the account identification for MERCH or COMG. If it is a Promise to Pay, the system proceeds with the following steps:
-
Matching Payment’s Reference 1 to Promised Payment’s Reference #1: The system finds a payment, referred to as a promise, where the reference 1 field of the promise matches the reference of the original payment.
-
Matching Payment’s Reference 2 to Promised Payment’s Reference #1: The system tries finding a promise where the promise’s reference #1 field matches the second reference of the original payment.
-
Matching Payment’s Reference 1 to Promised Payment’s Reference #2: The system tries to find a promise, in which the second reference of the promise aligns with the first reference of the original payment.
-
Matching Payment’s Reference 2 to Promised Payment’s Reference #2: The system finds a promise where the second reference of the promise matches the second reference of the original payment.
If a suitable match in one of the above steps is found, the process recognizes this as the Promise to Pay and the associated account and payer are recognized in the system. The original payment is then linked or Paired to the found Promise.
Non-Promise to Pay
If the incoming payment is not a Promise to Pay, the system identifies the payment according to a defined scenario. The system checks various combinations of payment references and document numbers to find a match. These combinations include:
The pairing process follows these steps:
-
Matching Document Numbers to Payment Reference #1: The payment is paired with a document if the document’s number matches the payment’s reference #1.
-
Matching Document’s Payment Reference #1 to Payment Reference #1: The payment is paired with a document when the document’s payment reference #1 matches the payment’s reference #1.
-
Matching Document Numbers to Payment Reference #2: The payment is paired with a document if the document’s number matches the payment’s reference #2.
-
Matching Document’s Payment Reference #1 to Payment Reference #2: The payment is paired with a document when the document’s payment reference #1 matches the payment’s reference #2.
Next, the process checks payer’s payment references:
-
Matching Payer’s Payment Reference 3 to Payment Reference #1: The system identifies a payer based on matching payment reference #1 with payer’s payment reference 3.
-
Matching Payer’s Payment Reference 3 to Payment Reference #2: In this scenario, payer is identified based on matching payment reference #2 with payer’s payment reference 3.
In the following steps, matching is done using both payer and document data:
-
Matching payer’s Payment Reference #1 and Payment Reference #1 & Matching Document Number and Payment Reference #2: Payment is matched to a document if payment’s reference #1 matches payer’s payment reference #1 and payment’s reference #2 matches the document number.
-
Matching payer’s Payment Reference #1 and Payment Reference #1 & Matching Document’s Payment Reference #1 and Payment Reference #2: Payment is matched to a document if payment’s reference #1 matches payer’s payment reference #1 and payment’s reference #2 matches the document’s payment reference #1.
Afterwards, the customer is drawn into the pairing process:
-
Matching Customer’s external ID to Payment Reference #1 – without leading zeroes: If external ID (after removing leading zeroes) of a customer matches payment reference #1, the payment can be attributed to this customer.
-
Matching Customer’s external ID to Payment Reference #1 – with leading zeroes: The payment is attributed to a customer when the customers’s external ID (with possible leading zeroes) matches payment’s reference #1.
-
Matching Customer’s external ID to Payment Reference #2 – without leading zeroes: If external ID (after removing leading zeroes) of a customer matches payment reference #2, the payment can be attributed to this customer.
-
Matching Customer’s external ID to Payment Reference #2 – with leading zeroes: The payment is attributed to a customer when the customers’s external ID (with possible leading zeroes) matches payment’s reference #2.
Finally, external document numbers are checked:
-
Matching External Document Number to Payment Reference #1: The payment is mapped to a document when external document number matches the payment reference #1.
If the incoming payment matches the registered document in any of the above steps, the payment is assigned to the document.
Unidentified Payments
If the incoming payment does not match any created document or promised payment, it is considered as an unidentified payment and the process ends.
Registering Payments
After the pairing process, the payment is registered and if there are no errors, the result is set to 'ok'.