Standalone Payments

A standalone payment is a one-time payment for a specific amount. Standalone payments are not part of a Payment Request or a recurring payment plan.

When you want to create single payment, you can decide between using standalone Payments and using single payments that are part of a Payment Request. Only in the following cases you can only use standalone payments:

If you want to use the Checkout integration for single payments.

Why can't I embed Payment Requests for single payments into my website via the Checkout integration?

A Payment Request for a single payment generates a link to the Checkout Experience, but if you're using the Checkout integration, the Checkout Experience is already embedded in your website, so a link isn’t needed for single payments.

If you want to create a single payment embedded within your website, you can use Checkout for Standalone Payments instead.

If you want to use Dynamic Links instead of Payment Request Links.

When should I use dynamic links?

Dynamic links are ideal for unspecific links that you want to re-use, for example a payment link on your website that always fills the Checkout Experience form with the same amount, but doesn't pre-fill any information about the payer since you don't know who will be clicking the link.
While you can also send dynamic links to a specific customer, they are not ideal since those links will ask the customer to pay each time they click on the link. This could result in duplicate payments (meaning the payer creates multiple payments in the Flywire system), even though Flywire has measures in place to try to prevent this.

Dynamic links allow you to provide a dynamic URL for receiving callbacks for the payment. If you don't provide a dynamic URL, the fixed URL of the portal will be used (if there is one).

What does dynamic and static callback URL mean?

There are two different URLs for receiving callbacks:

Static URL

A static callback URL is a fixed URL defined in your portal. All payments for this portal will send callbacks to this URL.

The static callback URL has been defined when your portal was set up. If you don't use a static callback URL yet and want to start using it, please reach out to your Flywire contact.

Dynamic URL

A dynamic callback URL is a URL that you define when you create the payment. Since this URL can be different for every payment you create, it is called dynamic.

For Pay-By-Link and Checkout , you define the URL via the callbackUrl parameter.

If you want to receive callbacks, you must provide a callback URL and a callback ID, otherwise no callbacks will be triggered. You also must set the callback version to 2.

You cannot provide a dynamic callback URL for payments that are part of a Payment Request. To receive callbacks about those payments, you have to use the static URL. Alternatively, you can use callback notifications for Payment Request status updates, but note that the content of those callbacks are different from payment status callbacks.

How defining static and dynamic URLs affect callbacks

= not set

= set

Static URL	Dynamic URL	Result
		You won't receive callbacks .
		You'll receive callbacks to your static URL. You'll also receive callbacks for payments that are part of Payment Requests.
		You'll receive callbacks to both URLs. You'll also receive callbacks for payments that are part of Payment Requests, but only to the static URL.
		You'll receive callbacks to your dynamic URL You will not receive callbacks for payments that are part of Payment Requests since there is no static URL.

How do Payments with Flywire work?

A payment with Flywire contains multiple steps:

You ask your customer to pay for something. You can do this by sending them a link to Flywire's Checkout Experience or by embedding the Checkout Experience into your website.
Your customer accesses the Checkout Experience and fills out the details to make the payment.

What is the Checkout Experience?

The Checkout Experience is the pop-up form that your customer accesses to make a payment. No matter how you ask your customer to pay - for example by sending them a link or by embedding the form on your website - they will always end up at the Checkout Experience to make their payment.
This creates a payment in the Flywire system.
Definition of a payment within the Flywire system
In everyday usage, a "payment" usually refers to the entire process of making a payment through Flywire. But the term "payment" has a specific meaning in Flywire:
1. A payment is considered created when a payment reference is assigned to it, not any earlier stage in the process.
  What is the payment reference?
  
  The payment reference is an ID generated by Flywire to identify a payment.
  
  Format:
  
  Either: ABC123456789
  
  3-letter portal/recipient ID 9 numbers
  
  Or: 1AB12CD452ABC1D
  
  number 8 alphanums number 5-alphanum portal/recipient ID
  
  With the payment reference, the payment can be tracked through the different stages of the payment process.
  
  The payment reference is also important in other situations, for example:
  
  When a payer is using bank transfer as payment method, they usually must provide the payment reference when sending the funds.
  
  The payment reference helps Flywire to identify the payment if you or your payer needs support.
2. When the payment reference is assigned, two things happen:
  - The FX rate is locked in for FX payments (FX = "foreign exchange", a payment where one currency has to be converted to a different currency).
  - The payment starts its journey in status initiated, and its progress traceable via the payment reference. If you are using Flywire Dashboard, you can view the payment on your dashboard.
Flywire processes the payment for you and disburses the funds into your account.

Links for Standalone Payments

Links for standalone payments (called "dynamic links") are stateless, meaning they don’t track if the payment has already been made.

Dynamic links are ideal for unspecific links that you want to re-use, for example a payment link on your website that always fills the Checkout Experience form with the same amount, but doesn't pre-fill any information about the payer since you don't know who will be clicking the link.
While you can also send dynamic links to a specific customer, they are not ideal since those links will ask the customer to pay each time they click on the link. This could result in duplicate payments (meaning the payer creates multiple payments in the Flywire system), even though Flywire has measures in place to try to prevent this.

Dynamic links allow you to provide a dynamic URL for receiving callbacks for the payment. If you don't provide a dynamic URL, the fixed URL of the portal will be used (if there is one).

What does dynamic and static callback URL mean?

There are two different URLs for receiving callbacks:

Static URL

A static callback URL is a fixed URL defined in your portal. All payments for this portal will send callbacks to this URL.

The static callback URL has been defined when your portal was set up. If you don't use a static callback URL yet and want to start using it, please reach out to your Flywire contact.

Dynamic URL

A dynamic callback URL is a URL that you define when you create the payment. Since this URL can be different for every payment you create, it is called dynamic.

For Pay-By-Link and Checkout , you define the URL via the callbackUrl parameter.

If you want to receive callbacks, you must provide a callback URL and a callback ID, otherwise no callbacks will be triggered. You also must set the callback version to 2.

You cannot provide a dynamic callback URL for payments that are part of a Payment Request. To receive callbacks about those payments, you have to use the static URL. Alternatively, you can use callback notifications for Payment Request status updates, but note that the content of those callbacks are different from payment status callbacks.

How defining static and dynamic URLs affect callbacks

= not set

= set

Static URL	Dynamic URL	Result
		You won't receive callbacks .
		You'll receive callbacks to your static URL. You'll also receive callbacks for payments that are part of Payment Requests.
		You'll receive callbacks to both URLs. You'll also receive callbacks for payments that are part of Payment Requests, but only to the static URL.
		You'll receive callbacks to your dynamic URL You will not receive callbacks for payments that are part of Payment Requests since there is no static URL.

If you want stateful links, consider using Payment Requests instead.

Ways to create a Standalone Payment

If you are using

Checkout : Checkout for Standalone Payments

If you are using

Pay-By-Link: Dynamic Links
(If you want stateful links, consider using Payment Requests instead)

If you are using

Elements: Checkout Sessions for One Off Payments

Tracking Payments

After the payment is made, you can track the payment’s progress and status via Client Dashboard.

Checkout

The Checkout implementation allows you to embed the Checkout Experience into your own website.

With Checkout, your payers never leave your website:

With the click of a button on your website the Checkout Experience form opens for the payer.
In the form, the payer can choose their preferred payment method and complete the payment.
After the payment is completed and the form is closed, the payer either is returned to the original page or is redirected to a page you specified.

You can use Checkout for the following payment types:

Grand Horizons Travel Website

Luxury Trip Package

Experience the ultimate luxury getaway with our exclusive travel package. Enjoy a 7-day stay at a five-star resort, gourmet dining, private tours, and much more.

Price: 5.000,00 €

Pay with the button below.

How to embed the Checkout Experience via Checkout

This simplified html example shows you how to implement the Checkout Experience in your website:

Script

Add the script that opens the Checkout Experience to your page.

The script source is

https://checkout.flywire.com/flywire-payment.js

Button

Add a button (or other element or event) to trigger the Checkout Experience form.

Event Handler

Add an event handler that defines what happens after the button is clicked.

Configuration

Set your portal specific payment configuration options. See List of Configuration Parameters for all parameters.

Render

Render the Checkout Experience form with the specified configuration.

<!DOCTYPE html>
<html>
  <head>
    <!-- Include the flywire.js script -->
    <script src="https://checkout.flywire.com/flywire-payment.js"></script>
  </head>
  <body>
    <!-- Add a button element -->
    <button onclick="pay()">
      Make Payment
    </button>

    <script>
      // Add an event handler
      function pay() {
        var config = {
          // See sample configuration options
        };

        var modal = window.FlywirePayment.initiate(config);
        modal.render();
      }
    </script>
  </body>
</html>

Pay-By-Link

Pay-By-Link is the lightest and easiest integration. You simply generate a link for your payer that you can implement into emails and other places. After clicking the link, your payer will be directed to the Checkout Experience outside of your website and all fields you provided values for via the link (for example payer's name or the payment amount) are already pre-filled.

There are two types of Pay-By-Link integrations depending on your use case:

Payment Request Links

Here you build links for Payment Requests via query parameters.

What are Payment Requests?

A Payment Request is a way to ask your customer to make a payment, typically by sending them a link. Unlike links for standalone payments, links to a Payment Request are stateful, which means they retain the information if a payment has already been made.

Examples for what your payer sees when accessing Payment Request links

	For a single payment, the link shows the amount to pay. Since the link is stateful, visiting the link again after the payment is made shows the information that the amount is already paid.
	For multiple installments, the link shows an overview about all installments in this request and lets the payer pay for them individually. Since the link is stateful, the overview gets updated whenever a payment is made.
	For subscriptions, the payer can save the payment method for all payments of this subscription. They also get an overview about past and upcoming payments of this subscription. Since the link is stateful, the overview gets updated whenever a payment is made.

Payment Requests also serve as an umbrella sitting on top of one or multiple payments. In Dashboard, the Payment Request tab shows you all different kinds of Payment Requests:

Another benefit compared to standalone payments is that Payments Requests can be edited after they are created, for example, you can add more payments to it (see Managing Payment Requests).

When should you use Payment Request Links?

Payment Request links are ideal for highly customized links you want to send to a specific customer. For example, you can insert them into an invoice or an email template and they pre-fill the Checkout Experience form with all the payer info and the payment amount.

Important info for payment callbacks: Ensure your portal has a static callback URL in place when you are using Payment Request links.

You cannot provide a dynamic callback URL for payments that are part of a Payment Request. To receive callbacks about those payments, you have to use the static URL. Alternatively, you can use callback notifications for Payment Request status updates, but note that the content of those callbacks are different from payment status callbacks.

What does dynamic and static callback URL mean?

There are two different URLs for receiving callbacks:

Static URL

A static callback URL is a fixed URL defined in your portal. All payments for this portal will send callbacks to this URL.

The static callback URL has been defined when your portal was set up. If you don't use a static callback URL yet and want to start using it, please reach out to your Flywire contact.

Dynamic URL

A dynamic callback URL is a URL that you define when you create the payment. Since this URL can be different for every payment you create, it is called dynamic.

For Pay-By-Link and Checkout , you define the URL via the callbackUrl parameter.

If you want to receive callbacks, you must provide a callback URL and a callback ID, otherwise no callbacks will be triggered. You also must set the callback version to 2.

You cannot provide a dynamic callback URL for payments that are part of a Payment Request. To receive callbacks about those payments, you have to use the static URL. Alternatively, you can use callback notifications for Payment Request status updates, but note that the content of those callbacks are different from payment status callbacks.

How defining static and dynamic URLs affect callbacks

= not set

= set

Static URL	Dynamic URL	Result
		You won't receive callbacks .
		You'll receive callbacks to your static URL. You'll also receive callbacks for payments that are part of Payment Requests.
		You'll receive callbacks to both URLs. You'll also receive callbacks for payments that are part of Payment Requests, but only to the static URL.
		You'll receive callbacks to your dynamic URL You will not receive callbacks for payments that are part of Payment Requests since there is no static URL.

Dynamic Links

Here you build links for standalone payments via query parameters.

A standalone payment is a one-time payment for a specific amount. Standalone payments are not part of a Payment Request or a recurring payment plan.

When should you use Dynamic Links?

Dynamic links are ideal for unspecific links that you want to re-use, for example a payment link on your website that always fills the Checkout Experience form with the same amount, but doesn't pre-fill any information about the payer since you don't know who will be clicking the link.
While you can also send dynamic links to a specific customer, they are not ideal since those links will ask the customer to pay each time they click on the link. This could result in duplicate payments (meaning the payer creates multiple payments in the Flywire system), even though Flywire has measures in place to try to prevent this.

Dynamic links allow you to provide a dynamic URL for receiving callbacks for the payment. If you don't provide a dynamic URL, the fixed URL of the portal will be used (if there is one).

What does dynamic and static callback URL mean?

There are two different URLs for receiving callbacks:

Static URL

A static callback URL is a fixed URL defined in your portal. All payments for this portal will send callbacks to this URL.

The static callback URL has been defined when your portal was set up. If you don't use a static callback URL yet and want to start using it, please reach out to your Flywire contact.

Dynamic URL

A dynamic callback URL is a URL that you define when you create the payment. Since this URL can be different for every payment you create, it is called dynamic.

For Pay-By-Link and Checkout , you define the URL via the callbackUrl parameter.

If you want to receive callbacks, you must provide a callback URL and a callback ID, otherwise no callbacks will be triggered. You also must set the callback version to 2.

You cannot provide a dynamic callback URL for payments that are part of a Payment Request. To receive callbacks about those payments, you have to use the static URL. Alternatively, you can use callback notifications for Payment Request status updates, but note that the content of those callbacks are different from payment status callbacks.

How defining static and dynamic URLs affect callbacks

= not set

= set

Static URL	Dynamic URL	Result
		You won't receive callbacks .
		You'll receive callbacks to your static URL. You'll also receive callbacks for payments that are part of Payment Requests.
		You'll receive callbacks to both URLs. You'll also receive callbacks for payments that are part of Payment Requests, but only to the static URL.
		You'll receive callbacks to your dynamic URL You will not receive callbacks for payments that are part of Payment Requests since there is no static URL.

From: [email protected]

To: Troy Traveler <[email protected]>

Subject: Your dream vacation

Grand Horizons Travel Experiences

Dear Troy Traveler,

We are excited to offer you an exclusive luxury travel package that promises an unforgettable experience. Enjoy a 7-day stay at a five-star resort, gourmet dining, private tours, and much more.

To secure your spot, please make a payment using the button below.

Sincerely,
The Grand Horizons Travel Team

Flywire Elements

Flywire Elements is an integration that provides access to a library of elements. These elements combine UI components (like input fields or dropdowns) with functionality (like charging a payment). You display them on your website to provide payment functionality.

This integration requires Flywire API credentials and the ability to make API requests for creating and confirming Checkout Sessions.

Smart Rendering

Smart Rendering means you render Flywire Elements on your website with the help of the Flywire SDK script.

Extensive customization

Select which payer fields to display, choose the language, and customize the appearance, such as fonts and colors.

Responsive layout

Optimized responsive layout for desktop and mobile devices.

Easy event handling

Simply define what should happen in case of success or errors - no need to filter individual postMessages.

As a fallback option, you can render Flywire Elements in an iframe on your website. The iframe sources a URL that is generated via the Flywire API.

Which Elements are available?

How do I implement Elements?

Implementing the Payment Element

Your Website

How would you like to pay?

Card

Just save new card

Save new card and make first payment

Use existing card

Direct Debit

SEPA

BACS

EFT Canada

ACH