Skip to main content
In some situations you may want to use guest buyer details but also use a stored buyer’s payment methods. For example, you may manage all the buyer billing and shipping details in your ecommerce platform and do not want to have to keep this in sync with the API. Yet, you also would like to offer a card-on-file experience at checkout where a buyer can use their stored payment methods. In these situations it makes sense to create a buyer record via the API with little to no details, passing all billing and shipping details as guest details, while using the buyer record just to link payment methods and transactions. Once created, you can use the buyer’s ID or external identifier to link a payment to that buyer, while only the guest details are passed to the payment services. 
{
    "amount": 1299,
    "currency": "AUD",
    "payment_method": {
        // This works with any payment method, 
        // as well as checkout sessions
        ...
    },
    // The buyer to link the payment (and any to-be-stored payment method) to
    "buyer_id": "e84fbc2a-3ee9-4ed5-9fc3-00c8e61fd8c5",
    // Alternatively use the buyer external identifier
    "buyer_external_identifier": "buyer-12345",
    // The buyer information used for this transaction.
    "buyer": {...}
}

​
Limitations

There are a few limitations to linking in-line buyer details to a stored buyer.
  • Any buyer ID and buyer external identifier provided need to match the same buyer record or they may be ignored
  • Any stored buyer details (name, email, addresses, etc) are ignored when guest checkout is provided. Guest data is not merged into any existing data, instead the guest data is the only data used.