TM Forum Community

 View Only

  • 1.  TMF676 Payment API for Refund and Payout

    Posted Nov 01, 2023 06:06
    Edited by Shrutika Ahuja Nov 13, 2023 04:29

    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 is not available in Billing to be sent towards 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
    ------------------------------



  • 2.  RE: TMF676 Payment API for Refund and Payout

    Posted Nov 01, 2023 06:33

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



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



  • 3.  RE: TMF676 Payment API for Refund and Payout

    Posted Nov 13, 2023 05:09

    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


  • 4.  RE: TMF676 Payment API for Refund and Payout

    Posted Nov 13, 2023 06:53
    Edited by Shrutika Ahuja Nov 14, 2023 02:30

    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


  • 5.  RE: TMF676 Payment API for Refund and Payout

    Posted Nov 14, 2023 03:10

    If this is a specific use case in a specific billing system, I don't think it could be applied to the API standard.

    You are at liberty to create a new entity type for your own implementation that models this particular type of transaction.



    ------------------------------
    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


Related Content