A payment token belongs to the merchant account that created it. A card saved at one of your locations is charged by that location, and every other merchant account is refused, even one you own.

Token sharing relaxes that within a single reseller. When a reseller turns it on, the merchants beneath it can charge one another's stored payment tokens, so a card saved at one location can be charged by another without the payer re-entering it.

It's off by default, and it covers processing only. This guide describes when it applies, what a reseller has to enable, which token handle works across merchants, and which credentials can use it.

When you'd use it

• One operator, several merchant accounts. Restaurant groups, MedSpa and clinic groups, and retail chains often run a separate merchant account per location for settlement and reporting, while the customer relationship is with the brand.
• Central ordering or booking. A head-office system takes the order, and the stored payment method was captured wherever the customer last visited.
• Moving a customer between locations. A subscription or contract that follows the customer to a new location keeps billing the card the customer already agreed to.

If all your traffic runs under one merchant account, you don't need any of this. Charging your own stored tokens never involves token sharing.

Turn on the reseller Token Sharing switch

Token sharing is a reseller-level capability, so a merchant can't self-serve it. Ask your reseller to enable it, or if you administer the reseller, open the reseller record, go to its feature switches, and turn on Token Sharing.

Four things to know about the switch:

• It's off by default. Until someone turns it on, every cross-merchant token charge is refused.
• It's required on both sides. The reseller of the merchant that owns the token and the reseller of the merchant taking the payment must both have it on. When both merchants sit under the same reseller, that's one switch. When they sit under a parent reseller and its child, each of the two resellers needs its own switch on, so no reseller can reach into another's merchants unilaterally.
• It takes effect immediately. WinkPG reads the switch on each charge, so the next request honors the change. No restart, no republish.
• It changes nothing about your own tokens. A merchant charging a token it created is unaffected in either state.

What the switch licenses, and what it doesn't

The switch licenses processing. It never widens who can see or manage another merchant's stored payment methods.

A merchant under an enabled reseller can	It still can't
Charge a sibling merchant's stored payment token as the tender on a sale or authorization	List or search another merchant's stored payment methods
Bill a sibling merchant's token from a recurring contract	Retrieve another merchant's token record through the token API, which answers 404
Collect through a platform-initiated billing run against a sibling merchant's token	Edit, deactivate, or regenerate another merchant's token

So a shared token is usable, not browsable. The owning merchant keeps full control of the stored method, and if it deactivates the token, every merchant's charges against it stop.

Address the token by its public reference

Send the pt_ public reference. It's globally unique, so it identifies one stored payment method no matter which merchant is charging it.

{
  "tokenData": {
    "token": "pt_9fKq2ZmB7tLxW3aH5nR8cV1s"
  },
  "invoiceData": {
    "amounts": { "base": 49.00 }
  }
}

The older numeric and card-format token strings aren't cross-merchant handles. WinkPG mints them per merchant account, so the same value can exist under two of your locations and identify a different card in each. Those forms resolve only inside the merchant account that's taking the payment. If your integration still stores them, capture the public reference for any card you intend to charge from more than one location. The Reusing a Stored Payment Method guide covers where the public reference is returned.

Which credentials can charge a shared token

Token sharing is exercised by reseller-level and platform-initiated callers, not by a merchant's own API key.

Caller	Can it charge a sibling merchant's token?
A merchant API key, or a user signed in to one merchant	No. A stored method that belongs to another merchant isn't visible to that credential at all, so the request fails as though the token didn't exist.
A reseller-scoped user or credential, acting for a merchant beneath it	Yes, when both resellers have Token Sharing on.
Recurring billing runs and merchant billing runs the platform executes	Yes, on the same both-sides condition.

That first row is the one that surprises integrators. It isn't a bug to work around: a per-merchant credential is scoped to its own merchant's vault by design, and widening it isn't what this switch does. Build cross-location charging on a reseller-scoped credential or on scheduled contracts.

What a shared charge looks like afterward

A charge that used a shared token records it. The transaction's token data carries tokenSharing: true and merchantOriginalId, the merchant account that owns the stored method, so you can identify shared charges later in reporting and reconciliation.

A refused charge fails as an ownership failure: the response says the payment token doesn't belong to the merchant. A scheduled charge that a contract or billing run submits fails the way any unusable stored method fails there, as an invalid stored payment token. There's no separate error code for token sharing, so nothing new to handle in your integration.

Enforcement is being phased in

Cross-merchant charging worked without any switch before this capability was gated, so refusing it immediately would break traffic that succeeds today. Your gateway operator controls when refusal begins, per environment, through the Transactions:TokenSharing:RefuseUnlicensedSharing setting.

While it's off, an unlicensed cross-merchant charge is still granted and recorded as a warning in the gateway logs, which is how an operator finds the resellers that need opting in before the change lands. Once it's on, the rules in this guide apply exactly as written. If you rely on cross-merchant charging, turn the reseller switch on now rather than waiting for the refusals.

Consent and card network rules to check first

Read this section before asking for the switch.

• Stored-credential consent is merchant-scoped. The cardholder agreed to store a card with the merchant that captured it. Charging that card under a different merchant account means a different merchant ID and a different statement descriptor for the cardholder, which is what they see and what they dispute against.
• Confirm your disclosure covers it. If you intend to charge a card across locations, tell the payer that at capture, and keep that evidence with the rest of your card-on-file terms.
• Merchant-initiated charges still need consent. Sharing doesn't replace stored-credential consent. An unattended charge without captured consent is declined whichever merchant submits it.
• Reader-captured methods can't be shared. When a stored method was captured by a decrypt-and-forward card reader, WinkPG holds no reusable card data for it, only a processor-side credential tied to the capturing merchant's processor profile. Another merchant charging it fails as an invalid stored payment token, whatever the switch says.

Confirm with your acquirer or reseller that your program permits it before turning the switch on for live traffic.

Troubleshooting

Symptom	Likely cause
The charge is refused as an ownership failure, and the switch looks on	Only one side is opted in. Check the reseller of the token's owning merchant and the reseller of the merchant taking the payment.
The token isn't found at all, and no ownership error appears	You're calling with a merchant-scoped credential. Another merchant's stored methods aren't visible to it, so resolution fails before ownership is considered.
A numeric or card-format token works for the owning merchant and not for a sibling	Those forms are per merchant account. Charge with the pt_ public reference instead.
A shared charge fails as an invalid stored payment token	The stored method is reader-captured and has no shareable card data, or the token was deactivated by its owner.
Charges stop working after a gateway update	Enforcement was switched on in that environment. Turn Token Sharing on for both resellers.
You can charge a sibling's token but can't see it in the stored payment methods list	Expected. The switch licenses processing only.

See also

• Reusing a stored payment method with payment tokens: where the public reference is returned, and how to charge it.
• Customers and saved payment methods: storing a payment method against a customer and capturing the consent a later charge needs.