On a checkout page, loading the PayPal Javascript SDK, I provide multiple merchant-ids like this (where [my_client_id] is replaced with my id, of course), the email addresses shown have been modified for privacy reasons:
<script src="https://www.paypal.com/sdk/js?client-id=[my_client_id]¤cy=EUR&locale=de_DE&merchant-id=*"
data-merchant-id="lobo***#gmail.com,suic***#squar***.de,einkauf#***-games.de,paypal#***.events,***#kst***.at"></script>
I then create a separate Paypal Smart button for each of the merchants. But although I provide the multiple merchant-ids, I will get the following error as soon as a payment button is clicked:
Error: Payee(s) passed in transaction does not match expected merchant
id. Please ensure you are passing merchant-id=****55TUNG or
merchant-id=lobo***#gmail.com to the sdk url.
But that merchant-id is provided in the URL as you can see above. If I press another merchant's pay button, I get the same error message but with that merchant's id listed in the error message.
The payee passed by the PHP script using createOrder is the corresponding email address of the merchant 100 percent correctly.
Is this a bug in the PayPal SDK or am I listing the merchant-ids maybe in the wrong way in the SDK-URL (though it is the way PayPal has described it a discussion on github)?
IMPORTANT SIDE NOTE: If I totally omit providing the merchant-ids in the SDK-URL, I get Javascript warnings about the missing merchant-id, but the payment buttons work just fine (which makes me sure that the PHP backend script is working 100 percent correctly), the payments are being processed.
What interesting, too: If I omit the merchant-ids in the SDK-URL, PayPal will render four different payment options, if I include the merchant-ids in the URL, then only two are shown (and both of them will throw the error).
All of this is referring to production mode.
Only pass a single merchant-id, and have it correspond to the payee that you are going to use.
Alternatively, pass no merchant-id at all, for transaction types that don't require it.
Related
I'm working on the integration with PayPal using the Smart Payment Buttons, and I need to catch the trxId generated when the user presses the "Pay With PayPal", when I print the info on the console, I can see the value I need, but when debugging or trying to get the value of the var, I'm getting undefined all the times, what I'm missing?
Below there's an image that explains the issue
My only guess so far is that there's some sort of security that prevents from getting this value?
There is no transaction at the time createOrder is called. The buyer hasn't even signed in at that point, much less given their approval, much less there have been a successful capture.
A transaction is only created after a successful capture.
onApprove: function(data, actions) {
return actions.order.capture().then(function(details) {
console.log(details); //Transaction's ID will be within this object
});
}
The above captures on the client side -- but you should not capture on the client side and then send data to a server.
If you need to do anything important with the transaction ID (such as store it in a database), you ought to be using a server-side integration instead. For this create two routes, one for 'Create Order' and one for 'Capture Order', documented here. These routes should return JSON data.
Pair your two routes with the following approval flow: https://developer.paypal.com/demo/checkout/#/pattern/server
Reading your question again, though, you mention an ID "at the time the button is clicked", so perhaps you meant to ask about the order ID rather than the transaction ID. Well the most obvious and best way to know the order ID is to directly create it on your own server.
I'm new to PayPal and its PDT. I've searched through many posts but they require Node.js or PHP to implement it. I don't have both, but I just want a simple return from PayPal PDT, telling my download.html that the purchase was successful so that I can safely display the product key to my customers and allow them to download my digital product, otherwise I will do something like this in my JavaScript:
If (purchaseFailed) {
window.location.replace('/404.html');
}
The reason that I do that is to prevent direct access to my download.html and reveal the product key without making a payment through PayPal.
I've enabled my PayPal PDT and specified the return URL, but I just do not know how to write the JavaScript to get the return the status from PayPal. I do not need to display any transaction detail to my customers except a 'thank you' message, the product key, and the download link (but if you can show some sample on getting the transaction details, e.g. product code and customer email address, that would help too). Can somebody help me with some simple JavaScript that my Google Blogger HTML can execute it? Thanks a lot!
PDT is completely unreliable, because returns are never guaranteed to happen, due to browser/network crashes or the customer not waiting for the auto-return (there is a timer) or not clicking through to return (typically guests w/o an account must be shown a receipt and click to return). So PDT is suitable for informational purposes only (e.g. showing buyers a thank you message when they do return.).
Absolutely no business logic such as downloads should depend on a PDT return actually occurring.
Instead, if you need a dependable notification from PayPal of payment completion, an asynchronous IPN or one of the newer webhooks should be listened for -- or alternatively, the integration should be changed to a more robust synchronous server-side one such as this pattern: https://developer.paypal.com/demo/checkout/#/pattern/server , where there is always an immediate API response on payment capture for notification purposes.
Blogger's HTML/JS does not provide any of the necessary listening or API capabilities, of course.
Sorry for the basic questions but as a very first step I'm just trying to test the "Log In with PayPal button JavaScript code builder".
I've created an app, gone to this button builder, set the return URL to my localhost and then as that failed to a public website (http://bbc.com) making the same settings on my app details page but whatever I do when clicking the button I get the following error:
"Relying Party Validation error: redirect_uri provided in the request does not match with the registered redirect_uri. Please check the request."
I've tried setting the button up for sandbox and production but both fail.
Has anyone had the same issue? I'm guessing I'm doing something really stupid. I'm just taking the "Dynamically generated JavaScript" code and adding it to an empty webpage.
Thanks.
Turns out it takes a while (a few hours) for the PayPal API to update to changes in the admin console. Changes were reflected after several hours, very unhelpful for testing. That was using the production option. Even when return_uri was being recognised as correct the scope settings were invalid despite selecting all the correct options.
How should I design an on-login middleware that checks if the recurring subscription has failed ? I know that Stripe fires events when things happen, and that the best practice is webhooks. The problem is, I can't use webhooks in the current implementation, so I have to check when the user logs in.
The Right Answer:
As you're already aware, webhooks.
I'm not sure what you're doing that webhooks aren't an option in the current implementation: they're just a POST to a publicly-available URL, the same as any end-user request. If you can implement anything else in Node, you can implement webhook support.
Implementing webhooks is not an all-or-nothing proposition; if you only want to track delinquent payments, you only have to implement processing for one webhook event.
The This Has To Work Right Now, Customer Experience Be Damned Answer:
A retrieved Stripe Customer object contains a delinquent field. This field will be set to true if the latest invoice charge has failed.
N.B. This call may take several seconds—sometimes into the double digits—to complete, during which time your site will appear to have ceased functioning to your users. If you have a large userbase or short login sessions, you may also exceed your Stripe API rate limit.
I actually wrote the Stripe support team an email complaining about this issue (the need to loop through every invoice or customer if you're trying to pull out delinquent entries) and it appears that you can actually do this without webhooks or wasteful loops... it's just that the filtering functionality is undocumented. The current documentation shows that you can only modify queries of customers or invoices by count, created (date), and offset... but if you pass in other parameters the Stripe API will actually try to understand the query, so the cURL request:
https://api.stripe.com/v1/invoices?closed=false&count=100&offset=0
will look for only open invoices.... you can also pass a delinquent=true parameter in when looking for delinquent customers. I've only tested this in PHP, so returning delinquent customers looks like this:
Stripe_Customer::all(array(
"delinquent" => true
));
But I believe this should work in Node.js:
stripe.customers.list(
{delinquent:true},
function(err, customers) {
// asynchronously called
});
The big caveat here is that because this filtering is undocumented it could be changed without notice... but given how obvious the approach is, I'd guess that it's pretty safe.
While trying to test local currency payment I see this error on javascript pay dialog callback:
{"error_code":1383003,"error_message":"Account id missing. sender: 235265828 receiver: 0"}
In facebook dialog I see this:
Sorry, but we're having trouble processing your payment. You have not been charged for this transaction. Please try again.
og:product object is correct (tested by Facebook Object Debugger), payments enabled, company for payments registered and selected, realtime updates script also selected and working.
I have no any ideas what to do. I found only one similar question with solution to set company for payments. And I tried to test payment by different users with different roles (developer, testers, administrators). Also in facebook error list I saw meager description for error 1383003:
1383003 - PaymentFailure - Processor decline.
It sounds like you don't have a company setup. That will definitely cause this error, try adding a tax ID in the company and see if you still get this issue.