TM Forum Community

Any payment or payout (confirmation/return) that could not be allocated in Billing due to erroneous scenario like Subscription-ID, Invoice-ID, Billing Account-ID, Case-ID etc., that could not be found in Billing, such transactions will get allocated in Lockbox within Billing.
There can be multiple options from Lockbox to handle such payment/payout.
One of the option to settle the payment from Lockbox would be to initiate the payout.
 
When any payout is initiated from Billing LockBox, the account details will not be known to the Billing and providing the  attributes :  account.Id, account.referredType, paymentMethod.id wouldn't be possible in Refund API (with v4.0).Currently all these attributes are marked as mandatory.

Hence, can you please guide how to process further in case, when payout is initiated from Billing Lockbox:
a) Should these attributes be marked as optional, which are currently marked mandatory in current v4.0? Will this violate the TMF guidelines? Will TMF team consider this scenario in upcoming releases?
b) Is there are a separate API already available that should be used when Payout is initiated from Billing Lockbox, where all the above attributes are either marked as optional or not mention at all?
c) Is there some other guidelines or suggestion already present to proceed the Payout from Billing Lockbox, when the account details can't be sent from Billing to Payment.

Another concern or feedback I had was about the correlatorId been marked as mandatory, if the payout is initiated from Billing, then  Billing generates the unique-id against PayoutRequestID, so keeping the track or marking the correlator id as the mandatory attribute is it suggestable ? Rather applying the retry mechanism or identifying the uniqueness should be on either of the three attributes : correlator id, payout request id or case-id (in case of refund initiated by CIM) and not on just one attribute i.e., correlatorId.

@Jonathan Goldberg, can you please assist me for the above concern been raised.

Any payment or payout (confirmation/return) that could not be allocated in Billing due to erroneous scenario like Subscription-ID, Invoice-ID, Billing Account-ID, Case-ID etc., that could not be found in Billing, such transactions will get allocated in Lockbox within Billing.
There can be multiple options from Lockbox to handle such payment/payout.
One of the option to settle the payment from Lockbox would be to initiate the payout.
 
When any payout is initiated from Billing LockBox, the account details will not be known to the Billing and providing the  attributes :  account.Id, account.referredType, paymentMethod.id wouldn't be possible in Refund API (with v4.0).Currently all these attributes are marked as mandatory.

Hence, can you please guide how to process further in case, when payout is initiated from Billing Lockbox:
a) Should these attributes be marked as optional, which are currently marked mandatory in current v4.0? Will this violate the TMF guidelines? Will TMF team consider this scenario in upcoming releases?
b) Is there are a separate API already available that should be used when Payout is initiated from Billing Lockbox, where all the above attributes are either marked as optional or not mention at all?
c) Is there some other guidelines or suggestion already present to proceed the Payout from Billing Lockbox, when the account details can't be sent from Billing to Payment.

Another concern or feedback I had was about the correlatorId been marked as mandatory, if the payout is initiated from Billing, then  Billing generates the unique-id against PayoutRequestID, so keeping the track or marking the correlator id as the mandatory attribute is it suggestable ? Rather applying the retry mechanism or identifying the uniqueness should be on either of the three attributes : correlator id, payout request id or case-id (in case of refund initiated by CIM) and not on just one attribute i.e., correlatorId.

Hi Shrutika

When say "Lockbox", I'm guessing that you are referring to a specific billing system that uses this concept. I'm not familiar with the term generally, although it may be my ignorance since I'm not a billing expert.

As a general point, mandatory properties in APIs are there because the API designer deemed them essential to the business. Payments and Refunds are intimately connected to a Billing Account, since they affect the account balance. And a Payment and Refund has a payment method, that's how the payment is collected or the refund is granted. I cannot see a scenario where these properties would not be populated.

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Original Message:
Sent: Nov 01, 2023 06:32
From: Shrutika Ahuja
Subject: TMF676 Payment API for Refund and Payout

@Jonathan Goldberg, can you please assist me for the above concern been raised.

------------------------------
Shrutika Ahuja
Tech Mahindra Limited

Original Message:
Sent: Nov 01, 2023 05:38
From: Shrutika Ahuja
Subject: TMF676 Payment API for Refund and Payout

Any payment or payout (confirmation/return) that could not be allocated in Billing due to erroneous scenario like Subscription-ID, Invoice-ID, Billing Account-ID, Case-ID etc., that could not be found in Billing, such transactions will get allocated in Lockbox within Billing.
There can be multiple options from Lockbox to handle such payment/payout.
One of the option to settle the payment from Lockbox would be to initiate the payout.
 
When any payout is initiated from Billing LockBox, the account details will not be known to the Billing and providing the  attributes :  account.Id, account.referredType, paymentMethod.id wouldn't be possible in Refund API (with v4.0).Currently all these attributes are marked as mandatory.

Hence, can you please guide how to process further in case, when payout is initiated from Billing Lockbox:
a) Should these attributes be marked as optional, which are currently marked mandatory in current v4.0? Will this violate the TMF guidelines? Will TMF team consider this scenario in upcoming releases?
b) Is there are a separate API already available that should be used when Payout is initiated from Billing Lockbox, where all the above attributes are either marked as optional or not mention at all?
c) Is there some other guidelines or suggestion already present to proceed the Payout from Billing Lockbox, when the account details can't be sent from Billing to Payment.

Another concern or feedback I had was about the correlatorId been marked as mandatory, if the payout is initiated from Billing, then  Billing generates the unique-id against PayoutRequestID, so keeping the track or marking the correlator id as the mandatory attribute is it suggestable ? Rather applying the retry mechanism or identifying the uniqueness should be on either of the three attributes : correlator id, payout request id or case-id (in case of refund initiated by CIM) and not on just one attribute i.e., correlatorId.

#OpenDigitalArchitecture

------------------------------
Shrutika Ahuja
Solution Architect
Tech Mahindra Limited
------------------------------

Thank you for the response @Jonathan Goldberg,

Yes, you are correct Lockbox entity is a specific Billing system, where after the payment is received to Payment Domain it passes the Payment Confirmation or Payout Return Event to Billing. Further Billing tries to identify the transaction and allocates the payment or payout return transaction but if Billing couldn't identify the account then it will allocate the transaction to "LockBox". So, the transaction would be like unallocated/unidentified transaction. 

Hence, providing the account details or Payment method for any such unidentified account would not be possible by Billing, if the payout is initiated from LockBox (unallocated/unclear payments).

Please suggest! 

------------------------------
Shrutika Ahuja
Tech Mahindra Limited

Original Message:
Sent: Nov 13, 2023 05:09
From: Jonathan Goldberg
Subject: TMF676 Payment API for Refund and Payout

Hi Shrutika

When say "Lockbox", I'm guessing that you are referring to a specific billing system that uses this concept. I'm not familiar with the term generally, although it may be my ignorance since I'm not a billing expert.

As a general point, mandatory properties in APIs are there because the API designer deemed them essential to the business. Payments and Refunds are intimately connected to a Billing Account, since they affect the account balance. And a Payment and Refund has a payment method, that's how the payment is collected or the refund is granted. I cannot see a scenario where these properties would not be populated.

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Original Message:
Sent: Nov 01, 2023 06:32
From: Shrutika Ahuja
Subject: TMF676 Payment API for Refund and Payout

@Jonathan Goldberg, can you please assist me for the above concern been raised.

------------------------------
Shrutika Ahuja
Tech Mahindra Limited

Original Message:
Sent: Nov 01, 2023 05:38
From: Shrutika Ahuja
Subject: TMF676 Payment API for Refund and Payout

Any payment or payout (confirmation/return) that could not be allocated in Billing due to erroneous scenario like Subscription-ID, Invoice-ID, Billing Account-ID, Case-ID etc., that could not be found in Billing, such transactions will get allocated in Lockbox within Billing.
There can be multiple options from Lockbox to handle such payment/payout.
One of the option to settle the payment from Lockbox would be to initiate the payout.
 
When any payout is initiated from Billing LockBox, the account details will not be known to the Billing and providing the  attributes :  account.Id, account.referredType, paymentMethod.id wouldn't be possible in Refund API (with v4.0).Currently all these attributes are marked as mandatory.

Hence, can you please guide how to process further in case, when payout is initiated from Billing Lockbox:
a) Should these attributes be marked as optional, which are currently marked mandatory in current v4.0? Will this violate the TMF guidelines? Will TMF team consider this scenario in upcoming releases?
b) Is there are a separate API already available that should be used when Payout is initiated from Billing Lockbox, where all the above attributes are either marked as optional or not mention at all?
c) Is there some other guidelines or suggestion already present to proceed the Payout from Billing Lockbox, when the account details can't be sent from Billing to Payment.

Another concern or feedback I had was about the correlatorId been marked as mandatory, if the payout is initiated from Billing, then  Billing generates the unique-id against PayoutRequestID, so keeping the track or marking the correlator id as the mandatory attribute is it suggestable ? Rather applying the retry mechanism or identifying the uniqueness should be on either of the three attributes : correlator id, payout request id or case-id (in case of refund initiated by CIM) and not on just one attribute i.e., correlatorId.

#OpenDigitalArchitecture

------------------------------
Shrutika Ahuja
Solution Architect
Tech Mahindra Limited
------------------------------