TM Forum Community

In case of BankCard as paymentMethod, what does TMF 676/POST mean ? 

Does it mean that payment is already collected from the card and the POST has to just record the payment ? 

Or does it mean that the product has to collect the payment from some payment gateway on receving TMF676/POST method ?

Hi Chandra,

TMF 676 is for recording payment event , and paymentMethod is ref to existing payment method managed via TMF670 Payment Method API.

Does it that payment is already settled externally before TMF 676 POST. Can you confirm.

It has status field you can use that and use POST/PATCH operation to create and update

TMF 676 document has no mention of the values status attribute can assume. Any reference document where list of the values status can take are documented?

------------------------------
Chandra Sekhar Runkana
Oracle Corporation
------------------------------

Subhanshu's framing is the right one: TMF676 records a payment event, and the instrument itself lives in TMF670. I'd add why the spec reads as ambiguous - it is deliberately silent on who does the collecting. Both readings are conformant. You have to pick one and write it into the ICD, because they fail in different places.

Pattern A, record-only: the channel or PSP has already authorised and captured, and the POST creates a payment that is terminal on arrival.

Pattern B, collect-on-POST: the platform calls the gateway, so the payment is created in a non-terminal state and transitions.

What actually breaks:

Authorisation is not capture. POST on auth and you have a "successful" payment that can quietly reverse at settlement. The bill shows paid, dunning stops, cash never lands, and nobody notices until someone reconciles two days later.

The 2am timeout. Collect-on-POST, gateway returns a 504. Did it charge? If you only persist after the gateway answers, you now have a charged customer and no payment resource anywhere in your estate. Persist a pending payment before the call, keyed to your correlation id.

Idempotency has to reach through to the gateway. A client retry on POST must reuse the same idempotency key downstream. Most double-charge cases I have worked through were an aggressive retry policy meeting an adapter that minted a fresh key on every attempt.

3DS and step-up auth. Any redirect means the payment cannot be terminal at POST time, so Pattern A stops being available for those flows.

On your open question about status: the spec does not normatively enumerate it. I would resist inventing a rich lifecycle. Keep a small set - pending, succeeded, failed, refunded/reversed - map PSP states into it inside the adapter, and make sure AR and dunning key off the settled state and never off the 201.

The question I would settle before the semantics: in your landscape, which system is the system of record for cash - the BSS or the PSP? Every argument I have sat in about POST semantics dissolved once that was answered, because it decides who is allowed to correct the payment when the settlement file disagrees on day T+2.