1

I've been messing around with Paypal's Payflow Pro and REST APIs they offer. I'm currently working on a .NET MVC Visual Studio solution that has its own shopping cart. Because of all the PCI compliance issues it seems that the safest route (only route?) is to post all secure data directly to paypal using AJAX. For me, this means posting all the cc #s, security codes, exp dates, etc. directly with jQuery AJAX. Nothing secure is going to hit my servers as it's going directly from the client to Paypal. This also means I'm going to be unable to use Paypal's SDK as most of this stuff is going to be dealt with on the client. At least I think this is the case.

Here's what I'm planning on doing, please comment/correct me if I'm wrong.

  1. User decides to 'checkout' and complete the sale (after entering shipping, billing, CC#, etc. onto one or more forms.
  2. User submits form, and I need to request a secure token from Paypal before submitting the payment request. For this I'll use an AJAX method to my server. Server method creates behind-the-scenes request (and un-sniffable with Fiddler, etc.) for the auth token (sends sends ClientID & Secret in Authorization header, to oauth2/token). Secure token returns in the response. AJAX request passes this time-sensitive token back to client.
  3. The request directly to Paypal is dynamically created (adding authorization header with Bearer token and other required json properties - intent, payer, funding_instruments, etc.)
  4. Response from this direct request contains the state of approval. Client displays status of payment, and other AJAX methods record the details of the approval on server for audit trails.

So, from what I've described above there's little, if any, use of Paypal's SDK. I can't use it on the client, and the request for the initial secure token is pretty straight forward (This helped me, though I'm doing it somewhat differently: Token Request Details ). The dynamic json of the request body might be ugly to build, but other than that I don't think this'll be too big of a deal (except for being time consuming to get it right!).

Does anyone see any problem with what I'm attempting here?

Community
  • 1
  • 1
RichieMN
  • 905
  • 1
  • 12
  • 33

1 Answers1

0

Top of my head, reliance on the client to give your server transaction/payment specific data (Paypal response to client script in #4).

  • I guess you could add a server side verification step on your end for this so that you can verify what essentially is "client provided info" (untrusted).

  • What about client side errors? You may need to add more checking to "sync" up with Paypal for all transactions (webhooks?)

Unless corrected by Paypal folk, I'm not sure "transparent redirect" (which what I think you want) is in REST API...or I missed it and in fact is what you're trying to achieve (in a different way, for PCI compliance - kudos on that btw :)).

That said, they do have transparent redirect in the Classic API.

I haven't used Paypal's transparent redirect specifically (other provider), but if minimizing PCI issues is your goal, perhaps that's a better way of getting there.

In a nutshell, you get a token that your HTML form will submit along with payer data directly to provider (never hitting your servers). Provider will then process the request and http redirect the user's browser back to your pre-defined URL. That predefined URL will then obtain the result from your provider.

In this flow, the user doesn't really "know" they left your web site (aka "transparent redirect").

Hth...

EdSF
  • 11,753
  • 6
  • 42
  • 83