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:
- 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).
- 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:
- Invoke the payment gateway with:
- the payment ref number of Step 1 (when amount was blocked)
- the amount to be deducted/settled
- the client id (belonging to the merchant) to which the amount needs to be credited
- action=settle
- 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
------------------------------