Open APIs

Expand all | Collapse all

TMF676 payment and refund life cycles need definition along with status values

  • 1.  TMF676 payment and refund life cycles need definition along with status values

    TM Forum Member
    Posted 26 days ago
    I have submitted https://projects.tmforum.org/jira/browse/AP-2846

    This issue identifies a few gaps I've identified in the Payment Management API to define the following.

    1. The status values (life cycle) for payment and refund.
    2. What methods can support the creation of a payment transaction that is not settled immediately, but initially contains an authorized (i.e., reserved) amount, which is later updated with a final amount for settlement.
    TMF676 appears to be underspecified in the above areas. The specification document contains TODO items for the life cycle status values for payment and refund. The specification does not explain how to accomplish the latter use case, and it is not obvious how the use case might be performed using the API.

    ------------------------------
    Ben Eng
    Oracle Corporation
    ------------------------------


  • 2.  RE: TMF676 payment and refund life cycles need definition along with status values

    TM Forum Member
    Posted 26 days ago
    We would also like to raise an issue with the Money type having a value of type float. This is a poor choice, because float is not precise. The type must be a fixed point decimal. A floating point number is unacceptable.

    ------------------------------
    Ben Eng
    Oracle Corporation
    ------------------------------



  • 3.  RE: TMF676 payment and refund life cycles need definition along with status values

    TM Forum Member
    Posted 24 days ago
    TMF676 is also underspecified for the use case where a Payment is created and it is later voided (partially or fully) with a Refund. It is unclear which property is specified to hold the Payment Gateway's transaction id returned by creating a Payment. The closest property for this purpose appears to be correlatorId. The use case would require that the Refund be created with this same transaction id, presumably carried on the request through the same correlatorId property. We would like the specification to describe this use case explicitly using examples, so that we can ensure interoperability.

    ------------------------------
    Ben Eng
    Oracle Corporation
    ------------------------------



  • 4.  RE: TMF676 payment and refund life cycles need definition along with status values

    Posted 20 days ago
    Yes. I agree. The contracts need to be aligned with use cases across industries.

    I have attempted to implement Payment and Payment Method API for an internal platform for an enterprise, as it is mostly a CRUD only specification, I had to make alignments as needed for the project.
    But  I think, Payment management is a such an important and vital function in any business system, it needs more comprehensive design for better adaptability.

    Thanks,
    Hanumantha M.
    OpenAPI Enthusiast.

    ------------------------------
    Hanumantha Marikanti
    Saralam Technologies
    ------------------------------