> ... and the payment processor sends a verification token to the vendor

I would just add one more critical step: the vendor actually verifies the verification token rather than just checking that it exists (since the token is often passed through the client, it can't be inherently trusted either). This should involve either hitting the processor's server or verifying a cryptographic signature, and verifying that the payment associated with the token matches what the vendor expects.

Why not have the payment processor notify the vendor's server directly? I believe PayPal does this.

That's how it works most of the time, at least in my experience.

Card details are sent to the processor, a token comes back. You then send the token along with any data relevant to the transaction (which items were purchased, tax zones, coupon codes etc), you then verify on the server that inventory exists etc, and then you send the token (which is only a short-lived represention of the credit card number) and then verify the payment went through, and then you go through the bussines process for delivering your product(s).

Then, and only then do you give back a response saying the order has processed, so the UI can alert the user.

this is essentially how stripe's implementation works.

CLient side library handles the CC and token generation. Server side you use that token to call stripes backend to process the payment.

Implementing IPN on Paypal is a pain. It is really only required because the normal flow for Paypal is to take the user off your site to theirs and only redirect back to you when the user clicks a link or waits quite a long time. This results in loads of users not making it back, or clicking out of the flow. More modern client-based payments processing tends to happen in-page via javascript or an app.

The Stripe/Braintree-style flow is nicest in many ways - they post the card details off to the payment processor, who generate a unique retailer-specific token for the card and send that back to the page. The retailer then uses that to process the payment server-side just like they would have done if they had collected the card number, only without the PCI-compliance issues.

That's not enough, the vendor needs to verify all the details that paypal sends back are correct.

Otherwise you can change the price and paypal will process your new price, then paypal returns a "yup, they paid" message back to the vendor.

If the vendor only checks they paid and doesn't verify all the other details against the basket you can adjust the price down.

I know this because I actually did this at one of my previous companies, we used to sell SMS bundles for use in our POS (point of sale) product. To demonstrate this vulnerability I lowered the price to a penny and bought our biggest bundle.

Because our test system had the payment side mocked* I had to use the live site.

What I hadn't counted on was the fact that our CEO was CC'd in whenever someone bought a bundle. Thankfully the company wasn't too large, so my boss was able to ask me about it and directly feed back what had happened.

* Technically "just not hooked up" rather than mocked.

Because then it's a 3-way conversation with nobody in the center. It's better to have the client do the transaction with the payment gateway, pass the token which they already have to your server on the orderPlace call which you then verify with the gateway. Otherwise the client could be asking for order confirmation before you know about the transaction.