We have a PayPal integration for a multi-merchant e-commerce site which has worked fine for the past two years. We've been having our members configure integration just by giving us the email address for their PayPal account.
In our checkout we have been loading the SDK with a tag like:
<script src=";[email protected]¤cy=USD&commit=false&locale=en_US&intent=authorize"></script>
where ABC_123_XYZ is our API client id from the PayPal developer portal, [email protected] is the email address for the seller's (not our!) PayPal account.
And then when setting up the 'purchase_units', we use:
'payee': {
'email': '[email protected]'
}
And it's worked fine.
Today (March 21 2025) we suddenly started getting the error message:
Error: Payee(s) passed in transaction does not match expected merchant id. Please ensure you are passing merchant-id=XXXXXXXXXXXXX or merchant-id=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX to the sdk url. /
Fortunately, they're giving us the merchant id in that error message. So after a failure for a member we can start using that ID in the SDK tag, and that seems to work. But making all our members suddenly provide their Merchant ID when they've been able to just use an email address is painful. If anyone has suggestions, or at least an explanation of what's changed that I can pass along, it would be appreciated.
We have a PayPal integration for a multi-merchant e-commerce site which has worked fine for the past two years. We've been having our members configure integration just by giving us the email address for their PayPal account.
In our checkout we have been loading the SDK with a tag like:
<script src="https://www.paypal/sdk/js?client-id=ABC_123_XYZ&[email protected]¤cy=USD&commit=false&locale=en_US&intent=authorize"></script>
where ABC_123_XYZ is our API client id from the PayPal developer portal, [email protected] is the email address for the seller's (not our!) PayPal account.
And then when setting up the 'purchase_units', we use:
'payee': {
'email': '[email protected]'
}
And it's worked fine.
Today (March 21 2025) we suddenly started getting the error message:
Error: Payee(s) passed in transaction does not match expected merchant id. Please ensure you are passing merchant-id=XXXXXXXXXXXXX or merchant-id=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX to the sdk url. https://developer.paypal/docs/checkout/reference/customize-sdk/
Fortunately, they're giving us the merchant id in that error message. So after a failure for a member we can start using that ID in the SDK tag, and that seems to work. But making all our members suddenly provide their Merchant ID when they've been able to just use an email address is painful. If anyone has suggestions, or at least an explanation of what's changed that I can pass along, it would be appreciated.
Share Improve this question asked Mar 21 at 4:46 Tom SwissTom Swiss 492 bronze badges 2 |2 Answers
Reset to default 3Exact same issue for me. Popped up all of a sudden.
In my case i solved it by not setting the merchant-id at all since i use standalone buttons and as per documentation: https://developer.paypal/sdk/js/configuration/#merchant-id
Don't pass a merchant ID, because it is automatically derived.
In the console i still get the warning though: Payee(s) passed in transaction does not match expected merchant id. Please ensure you are passing merchant-id=xxx or merchant-id=xxx to the sdk url.
In the past we got: Payee(s) passed in transaction does not match expected merchant id. Please ensure you are passing merchant-id={ID} or merchant-id={EMAIL}
So maybe something has changed on their end and they dont allow email
anymore?
i have same issue. I fixed it by removing merchant-id from sdk url. I keep the payee object with merchant email.
integration-date
can make it revert back to the old behavior? I would not hold out too much hope, because this appears to be mainly geared towards controlling how the SDK behaves client-side when it comes to new features, whereas the rejection of the email instead of an ID is probably more a "server-side" issue - but worth a try at least, I suppose. – C3roe Commented Mar 21 at 12:02