Any good solutions to make my existing payment logic more interoperable with PayPal?

staletidings 0
Viewed 16

I'm working on a project that's using Sofort to accept payments. Sofort strong-arms me into adopting this paradigm:

  1. I send a request to Sofort, containing

a) my API-token (so that Sofort sends the captured payment to my bank account)

b) a user_variable. Here I just input my local UID of the the user who wishes to make a payment. This enables me to use my own local UIDs to cross-reference Sofort-payments with my local user database.

c) A notification_url, essentially a webhook URL which enables me to asynchronously listen to payment updates (pending, completed, rejected etc.)

  1. Sofort then returns a URL which handles the entire payment process. I send this URL to the front-end where it's opened in a webview.

  2. If my webhook then receives a "completed" notification object, it checks the user variable (my own local UID which Sofort forwards to the webhook, a key piece of functionality that makes this work. Don't know if Paypal has something similar), the amount, and credits that amount to the user.

In anyone's Paypal API experience, is it possible to create a PP data flow which at least rhymes with this paradigm?

Two keynotes:

  • These are one-time payments. Not subscriptions.
  • The actual under-the-hood logic is essentially a bank. There is a local registry of users, each with a UID and a balance. Any payment made by a particular user should be credited to their account.
payment paypal api
1 Answers

You could implement PayPal Checkout plus also PayPal Webhooks to be notified of payment attempts, but doing so (even though it may be more similar to your existing Sofort implementation) will be (a) more work, and (b) less reliable than simply implementing PayPal Checkout by itself with a server-side integration that captures via API, and does not rely on any asynchronous webhook after the fact.

--

Use the v2/checkout/orders API and make two routes (url paths) on your server, one for 'Create Order' and one for 'Capture Order'. You could use one of the (recently deprecated) Checkout-*-SDKs for the routes' API calls to PayPal, or your own HTTPS implementation of first getting an access token and then doing the call. Both of these routes should return/output only JSON data (no HTML or text). Inside the 2nd route, when the capture API is successful you should verify the amount was correct and store its resulting payment details in your database (particularly purchase_units[0].payments.captures[0].id, which is the PayPal transaction ID) and perform any necessary business logic (such as reserving product or sending an email) immediately before forwarding return JSON to the frontend caller. In the event of an error forward the JSON details of it as well, since the frontend must handle such cases.

Pair those 2 routes with this frontend approval flow: https://developer.paypal.com/demo/checkout/#/pattern/server . (If you need to send any additional data from the client to the server, such as an items array or selected options, add a body parameter to the fetch with a value that is a JSON string or object)

That approval flow can be customized to show as many or as few of its buttons as you want (use the disable-funding parameter, or standalone buttons) and then Sofort can be another option you render on its page

Preston PHX0
Related