Open APIs

 View Only

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

    Posted Aug 31, 2021 12:08
    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

    Posted Aug 31, 2021 22:21
    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

    Posted Sep 02, 2021 11:01
    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 Sep 06, 2021 02:01
    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
    ------------------------------

    Original Message


Related Content