Account sharing

Account sharing lets another organisation work with merchant accounts that belong to your platform, with each merchant’s permission. It exists for accounts that someone else provisioned. For the merchants your own platform creates, you don’t need it: your API key already reaches all of them.

Account sharing is available on request. Contact Shuttle support to enable it for your application.

Use cases

One platform collects, another charges. A hotel booking engine collects a guest’s card through Shuttle, and the card is saved against the hotel’s account at its processor. The hotel’s property management system connects to the same account through account sharing and charges that saved card: a deposit, a no-show fee, the balance at checkout. Neither system integrates the hotel’s processor, or any processor: both reach the processors Shuttle supports through the one account, and the card details never pass between them.

The same shape fits anywhere one system takes the payment details and another bills against them: a booking system and a practice management system, an online shop and an order management system, a signup form and a billing platform.

AI agents taking payments by phone. An AI voice agent takes the customer’s card during the call, through Shuttle’s phone payments, so the number never reaches the agent or the call recording. On its own, that leaves the payment in an account the merchant’s other systems can’t see. If the system that fulfils the order (the booking, the policy, the invoice) connects to the same account through account sharing, it can be told about the payment by webhook as soon as it is taken, and charge the saved card again later, with no card details handed between the two.

Payment Links. Shuttle’s own Payment Links app shares its merchants’ accounts this way, so that platforms can create payment links for them: see Connect to Payment Links accounts.

Workflow tools. A tool such as Zapier or Make can create payment links or react to payments in a merchant’s account, as part of the merchant’s own automations.

Who’s involved

	Who	What they do
Owner	The platform whose merchants they are	Lets its merchants connect their accounts to the Merchant Portal, and creates an OAuth client for each third party it shares with
Third party	The organisation being given access, such as a property management system or a workflow tool	Sends merchants through the OAuth flow with the client it was given, then calls the API with each merchant’s access token
Merchant	The business that owns the account	Logs into the Merchant Portal and chooses which of its accounts the third party can use

How it works

1. The merchant connects their account to the Merchant Portal. While setting up their payment processor in your onboarding, the merchant can connect the account to a Merchant Portal login. See Merchant Portal connections.
2. You create an OAuth client for the third party. You give them its client ID and client secret. See Creating OAuth clients.
3. The third party asks the merchant for access. It sends the merchant to Shuttle, where they log into the Merchant Portal, pick one of their accounts on your platform, and grant access. See Connecting to shared accounts.
4. The third party uses the API for that account. It receives an access token for the chosen account and calls the API with it. See Calling the API with an access token.

Access can be taken away again: see Removing access.

Sandbox and live

Sharing works separately in each environment. A third party needs a client for your sandbox application to connect to sandbox accounts, and one for your live application to connect to live accounts.