Understanding Facebook payments Fulfillment flow

Question

I'm learning how to implement Facebook Fulfillment flow. I can't make sense of using request_id (steps 1 & 2). The idea is that my server generates request_id and later when the app get encoded response from Facebook, compare details in that response with the stored details on my server (using request_id as a key).

What is the purpose for this validation?

It says:

The most secure way to verify an order is to use the signed_request parameter from the JavaScript callback, as this has been encoded using the App Secret and can't be manipulated by the client.

So, if we trust this data and it can't be manipulated, why we need for the additional check? If, in other hand, it can be manipulated, how this measure prevents from simple passing the same request to my server and use returned request_id as part of creating manipulated signed_request.

Answer 1

Let's break it down and try to understand the use the use of signed_request.

It says, The most secure way to verify an order is to use the signed_request parameter from the JavaScript callback, as this has been encoded using the App Secret and can't be manipulated by the client.

The signed_request is encoded by Facebook servers using app secret that only Facebook & the App Developer knows. No other client will be able to generate signed_request without the secret key. Hence this is the most secure way to verify an order.

How can a client manipulate signed_request?

If your site is vulnerable to XSS, an attacker can inject javascript code into your application.

How will the app server knows that the signed_request is not generated by Facebook?

When the app server receives the signed_request, it must verify the signature of the singed_request. The signature verification will only succeed if it was generated by Facebook because only Facebook have your secret key.

The method of verifying the authenticity of digital data is known as Digital Signature.

Answer 2

There are tow reasons of using request_id

This information can then be used later in the payment flow to verify that the purchase wasn't manipulated in between the client and server, or to retrieve a payment via a call to the Graph API in instances where the Payment ID isn't known.

1. Although data can't be manipulated, It ensures extra security.
2. It makes possible to retrieve a payment without using Payment ID.

Note: request_id is optional and you can definitely serve the purpose using alternative ways.

10. The Developer Server verifies the payment by decoding the signed request from the Client and using the payment verification payload in one of the following 2 ways:

    1. Using the request_id parameter to compare the purchase details against the persisted data from step1.
    2. Making a call to Facebook Graph API to confirm that the payment details are as expected

By using signed_requestthere are 2 ways to verify the payment.

1. If you generate the request_id you can verify without having any further request to FB server because of the request_id is reserved in your database. So it is one of the advantages of using request_id that you can avoid extra request like calling Graph API.

2. If you have not any request_id then you have to use the Payment ID and make a request to FB again.

See more on the Verification via Graph API section.