💳Introduction

Since Apple and Google both introduced tap to pay terminal APIs and Stripe's recent efforts to roll this out across US/EU it seemed a great idea to expand this plugin to support the use of Stripe terminal with connected accounts.

Information on the new Tap to Pay experience can be found here: https://stripe.com/gb/terminal/tap-to-pay

Only compatible with native applications

This plugin completely supports the use of terminals both comaptible bluetooth devices and tap to pay when used with native compiled applications. This includes React Native, Flutter and Ionic Capacitor applications.

This plugin only handles the server side requests needed to facilitate an in-person payment experience. You will need to implement the native / client-side functionality yourself.

Depending on your approach you can either use the seaparate iOS / Android terminal SDKs, the React Native SDK, or implement your own.

I am working on an Ionic Capacitor plugin that will enable anyone using Ionic to utilise Stripe Terminal.

Structure

It is important to understand how the Stripe Terminal SDK works. Specifically how the prerequisite entities are structured and what needs to be set up per connected account before you are able to take payments.

The basic structure is as follows:

• Zone (A recursively hierarchical entity for grouping locations together)

• Location (A physical loaction that represents where the terminal reader belongs to)

• Reader (A registered physical device used for collecting payments in person)

  • This can either be a mobile device supporting tap to pay or a stripe approved bluetooth device.

  • A full list of compatible devices can be found here: https://stripe.com/gb/terminal

• Connection Token (An encrypted token used to represent the connection session to the Reader)

Prerequisites

In order to make a payment using a reader, you must ensure the following process is followed:

• A location exists for the reader to belong to

  • This can represent the office or building the reader is based at, if the reader is to be used remotely or away from the office, you can simply use the business address as the location.

• The reader device must be registered and assigned to the location

  • Bluetooth readers is less straight forwrard, and the experience for the user will vary per device.

    • The common denominator is that all devices will generate.a registration code that can be entered into stripe via the registartion function this plugin provides in order to complete the registration

• An endpoint must exist for the client side application to communicate with in order to retrieve new connection tokens. A function is provided within the plugin for this, see the connection tokens page.

Destination Vs Direct charging models

Depending on how you wish to handle charges, direct or destination you will need to ensure the above pre-requisite entities exist on the correct owning account. This is the same as for Payment intents. Basically, the requried objects must belong to the same account as the payment intent. Otherwise it will simply fail.

With direct charges, the above required objects must belong to the connected account rather than the platform. The connected account is responsible for the cost of Stripe fees, refunds, and chargebacks.

When using destination charges, the above required objects belong to your platform account. Each payment creates a transfer to a connected account automatically.

We've tried to make it as simple as possible, all of our terminal functions have a $direct variable which defaults to false, but if set to true, will run that endpoint against the connected account.