Payments Relations

These are the extension link relations defined by the Payments API. Each one is identified by its full tag URI — the short name in the table is the suffix after tag:flywire.com,2016:agents:api:relation:.

Relation	Description
intermediated-payments	Collection of payments intermediated by the agency.
intermediated-payment	Details of a single intermediated payment.
payment-receipt	Downloadable payment receipt.
payment-confirmation	Downloadable payment confirmation.
claim-intermediation-of-payment	Entrypoint into the process of claiming intermediation of a payment.
confirm-intermediation	Final step of the claim-intermediation process.
payment-recipients	Browse and drill into the catalogue of payment recipients.
standard-payment-experience	Create a standard payment experience for the context recipient.
set-up-payment-experience	Create a payment experience that needs user input.

See also: Common Relations for the IANA-registered relations (self, first, prev, next, last, payment, …) shared with the Insurance API. That list is not exhaustive — clients should be prepared to encounter any IANA-registered relation alongside the extension relations above.

intermediated-payments

The target resource facilitates iteration over the set of payments intermediated by the agency. Representations generated by such resources comply with the hypermedia, item and intermediated-payments profiles. Such resources can only be fetched (i.e. GET is the only method they support).

intermediated-payment

The target resource provides details about an intermediated payment. Generated representations comply with the hypermedia and intermediated-payment profiles.

payment-receipt

The target resource presents a downloadable payment receipt. Opens externally; not intended for server-to-server traversal.

payment-confirmation

The target resource presents a downloadable payment confirmation. Opens externally; not intended for server-to-server traversal.

claim-intermediation-of-payment

When fetched, the target resource will initiate a process at the end of which a payment is acknowledged as being intermediated by the agency. It does this by responding to GETs with a form that defines, through its inputs field, the shape of the data that is required for the claim to be considered. Once collected, this data can then be POSTed back to the resource to continue the process. Next steps will be exposed through the links presented in the representation of the response.

confirm-intermediation

This is the final step of the process through which the API acknowledges the intermediation of a payment by an agency. It can be taken by POSTing with no request body on the target of such a link. No other method is supported by these resources.

payment-recipients

The target resource is the starting point for the process of creating payment experiences for the institutions served by Flywire. Such resources generate representations that comply with the hypermedia and payment-recipients profiles, and can only be fetched.

They are designed to be exposed to users through a UI that presents the contents as a list (dropdown or otherwise) from which they can choose one of the entries and either create a payment experience for it if it is a recipient (depending on the exact nature of the recipient, it might not be possible to directly create standard experiences for it, instead requiring setting one up through collecting data about it from the user), or navigate to its subset of payment-recipients if it is a group.

standard-payment-experience

POSTing with no request body on the target of such a link will create a standard payment experience. The context of such links will determine the concrete setup of the experience. No other method is supported by these resources.

set-up-payment-experience

The target resource allows the creation of a payment experience that requires user input or can be customized by them. It does this by responding to GETs with a form that defines, through its inputs field, the shape of the data that is either required or customizable. Once collected, this data can then be POSTed back to the resource to create an experience based on it. The context of such links will determine the exact payment recipient for which the experience will be created.