Why you'll be losing a lot of business
Why we ditched PayPal for Stripe
111–120 of 120 posts
Re: Why we ditched PayPal for Stripe
#112Earlier quoted context omitted.
The rant was about the retry algorithm, which (from reasonable interpretations of the documentation) seems to "clear" (for lack of a better term) the IPN during a successful "response" (the term used in the PDF), but where a "response" seems to be defined as the verification step, not the HTTP request returning a successful status code. If this were the case (and it seems from other responses to the rant that it is n…
I still don't totally understand the issue. If your commit fails you can return a "500 error" which will cause the IPN to retry. I can see how the validation step might be confusingly described. For what it's worth, the validation step merely compares a hash of the variables to confirm the authenticity of the IPN. It doesn't touch the DB at all.
The reason you don't understand the issue is because it is implemented correctly, which is why I kept pointing out the responses to the rant that indicated he was wrong about how it actually worked (to make clear I understood this, apparently failing ;P), and kept adding the parenthetical hedges about the documentation. Really: you nailed it, and the PayPal IPN mechanism works great (seriously: no sarcasm).
The rant really was just about how he perceived it working based on what I do feel is a reasonable reading of the documentation (and in fact I think I originally had that interpretation myself until I actually tried it in practice): that the documentation lists the "response" as the verification process, and does not seem to have any provisions for "500 error": again, though, the way it works is fine.
Re: Why we ditched PayPal for Stripe
#113Re: Why we ditched PayPal for Stripe
#114Can someone explain why Stripe doe not allow marketplace transactions but WePay does? Is this primarily due to issues of fraud? If so, how does WePay get around it?
Re: Why we ditched PayPal for Stripe
#115We switched to Stripe from Paypal and Google Checkout a month ago and so far I've been very, very pleased. I plan to do a writeup of why we switched soon - wanted a bit more results first. FYI, Stripe launched a new web interface 2 days ago. The net bottom line was this: 1. our customers (business people who are not super tech savvy) just don't understand that you can pay with a credit card on paypal and google check…
Stripe does provide you with a merchant account (https://stripe.com/terms). They just make it a simple process by asking for as little info up front as possible. There's advantages to this such as a quicker sign up process. But the disadvantages are that you may have issues if your company grows too fast, if you get too large of a transaction size or a host of other risk issues. Your best protection against these is giving the bank the option to perform a thorough underwriting. Disclosure: I work at Braintree.
Re: Why we ditched PayPal for Stripe
#116Earlier quoted context omitted.
I am not familiar with A/B/C/D levels but PCI spec clearly defines PCI 1-4 levels based on volume/number of payments: http://www.pcicomplianceguide.org/pcifaqs.php#5
Ah, yes. What I'm talking about above applies to level 4 merchants, (less than 20k ecommerce transactions), who can get away with lower level compliance. The ABCD levels refer to the self assessment questionnaires (SAQ) these level 4 merchants are required to completed. https://www.pcisecuritystandards.org/security_standards/docu...
I guess I never bothered to look at anything below level 1 :)
Re: Why we ditched PayPal for Stripe
#117The post is spot on. My initial attraction to Stripe was because of a reason mentioned in the post: not wanting to redirect or otherwise interrupt the normal order process of my site with another company's (branded) checkout form just to handle credit card payments. The other reason for initial attraction was of course their elegant API, which was very refreshing to see after having dealt with Intuit's QBMS API ( shu…
You almost always get amazing customer support from early stage companies. I'm certain people got amazing customer support from people high up at PayPal when it was just starting. You cannot judge a company on whether a co-founder responds to you on Twitter in a short period of time, and if you did, you should probably judge it negatively: I would wonder what was wrong with PayPal if someone that high up had enough t…
> I'm certain people got amazing customer support from people high up at PayPal when it was just starting.
Can you imagine what that could have been like?
Customer: yeah I've having trouble accessing the purchase history
Support (Elon Musk): you need to twiddle the such-and-such.
Customer: tried that. can you escale to your superior?
Manager (Peter Thiel): can I help? I want to make personally sure you have a great experience. Also, avoid college. I'll pay you.
Re: Why we ditched PayPal for Stripe
#118We switched to Stripe from Paypal and Google Checkout a month ago and so far I've been very, very pleased. I plan to do a writeup of why we switched soon - wanted a bit more results first. FYI, Stripe launched a new web interface 2 days ago. The net bottom line was this: 1. our customers (business people who are not super tech savvy) just don't understand that you can pay with a credit card on paypal and google check…
Stripe does provide you with a merchant account ( https://stripe.com/terms ). They just make it a simple process by asking for as little info up front as possible. There's advantages to this such as a quicker sign up process. But the disadvantages are that you may have issues if your company grows too fast, if you get too large of a transaction size or a host of other risk issues. Your best protection against these i…
I work at Stripe. This is pure FUD. If fast-growing companies really did encounter problems with Stripe, don't you think at least one would have talked about it?
Re: Why we ditched PayPal for Stripe
#119Earlier quoted context omitted.
I still don't totally understand the issue. If your commit fails you can return a "500 error" which will cause the IPN to retry. I can see how the validation step might be confusingly described. For what it's worth, the validation step merely compares a hash of the variables to confirm the authenticity of the IPN. It doesn't touch the DB at all.
The reason you don't understand the issue is because it is implemented correctly, which is why I kept pointing out the responses to the rant that indicated he was wrong about how it actually worked (to make clear I understood this, apparently failing ;P), and kept adding the parenthetical hedges about the documentation. Really: you nailed it, and the PayPal IPN mechanism works great (seriously: no sarcasm). The rant…
You are being far too generous regarding the documentation. Here's the relevant part:
---
The IPN protocol consists of three steps:
1. PayPal sends your IPN listener a message that notifies you of the event
2. Your listener sends the complete unaltered message back to PayPal; the message must contain the same fields in the same order and be encoded in the same way as the original message
3. PayPal sends a single word back, which is either VERIFIED if the message originated with PayPal or INVALID if there is any discrepancy with what was originally sent
Your listener must respond to each message, whether or not you intend to do anything with it. If you do not respond, PayPal assumes that the message was not received and resends the message. PayPal continues to resend the message periodically until your listener sends the correct message back, although the interval between resent messages increases each time. The message can be resent for up to four days.
---
This is clear, unambiguous, and - if what you say is correct - just flat out WRONG. My misunderstanding wasn't just "a reasonable interpretation", its the only reasonable interpretation. At the barest minimum, competent documentation should state "PayPal will attempt to resend messages until your handler returns a 200 OK http status code." It doesn't. Anywhere.
This is a perfect example of why working with PayPal is an unacceptable developer experience. And who doubts that one year from now this document won't have changed one bit?
Re: Why we ditched PayPal for Stripe
#120Earlier quoted context omitted.
The reason you don't understand the issue is because it is implemented correctly, which is why I kept pointing out the responses to the rant that indicated he was wrong about how it actually worked (to make clear I understood this, apparently failing ;P), and kept adding the parenthetical hedges about the documentation. Really: you nailed it, and the PayPal IPN mechanism works great (seriously: no sarcasm). The rant…
You are being far too generous regarding the documentation. Here's the relevant part: --- The IPN protocol consists of three steps: 1. PayPal sends your IPN listener a message that notifies you of the event 2. Your listener sends the complete unaltered message back to PayPal; the message must contain the same fields in the same order and be encoded in the same way as the original message 3. PayPal sends a single word…
It's not the best wording but doesn't necessarily imply that the payment is dependent on handling the IPN, just that the retrying is affected by the handling.
But it is unforgivable that there does not seem to be any mention of what response the PayPal server is expecting to indicate that the IPN has been successfully caught.