Open APIs

  • 1.  TMF676 - Deposit settlement

    TM Forum Member
    Posted Oct 05, 2021 12:39
    Hi all,

    First off - a big thank you to TMForum and this vibrant community - thanks to the support we have been able to TMF-ify a good number of our apis.

    The issue I am faced with today is related to a use case where we collect a refundable deposit from customers (who have a low credit score). We do this in case we need to dispatch them high value equipment (mobile phones, routers) as part of the order.

    Collecting the deposit is a 2 step process in our system:
    1. As part of the order journey, we allow the customer to enter the card details and block with deposit amount on the card (this happens via an existing non-TMF legacy interface - PCI compliant).
    2. After the order has been placed, once we are sure that the order can be provisioned successfully - we settle/deduct the amount from the card (this is a new api we are building)
    My question is related to the settlement step (2nd step) above.

    The logic that would be implemented by this api to realise step 2 would be:
    1. Invoke the payment gateway with:
      1. the payment ref number of Step 1 (when amount was blocked)
      2. the amount to be deducted/settled
      3. the client id (belonging to the merchant) to which the amount needs to be credited
      4. action=settle
    2. Once step (a) succeeds, we update the billing system with the credit - with payment charge type as Deposit (refundable)

    The question(s) I have are:
    - Could I use the POST operation of TMF676  (Payment Management API) to do the above steps (a) and (b)?

    - Given that 2 things are happening behind the scenes - invoking the gateway (step a) and updating billing (step b)  - would it still be ok to employ TMF676 - or does TMF676 strictly mean that we need to only deal with payment and not billing system update?

    Any help/pointers would greatly be appreciated.

    Thank you.

    Anand Paul
    BT Group plc

  • 2.  RE: TMF676 - Deposit settlement

    TM Forum Member
    Posted Oct 06, 2021 04:52
    Hi Anand,

                  TMF676 deals with processing of Payments and Refunds, it does not deal with financial implication of these activities on the billing account.

                   In my view your suggestion of using TMF 676 for step (a) is perfectly valid. However step (b) does not fall in it's purview. In your example you are planning to treat the amount coming through this payment as refundable deposit, in some other scenario a Payment might result into impacting the open balance, so all such financial activities are not in scope of the Payment. We do plan to define new APIs for all the financial activities like Credit, Deposit, Write-off etc. in near future. I believe your step (b) will need to use one of those APIs based on how the Payment is expected to impact the billing account.


    Nitin Patil
    Portfolio Architect BSS + B2B
    Amdocs India 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