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.
This is a duplicate post, please follow the discussion on the other thread https://engage.tmforum.org/discussion/tmf676-payment-api-for-refund-and-payout