After switching to the new Facebook local currency API the process is working, but
my server is not involve in the process so i really don't know if the user bought coins cause the payment callback URL is not being called now (using static payment).
I tried to use real time update to get Facebook data but can make it work, what is the best practice to involve the server in the process so it will be aware of the purchase?
I prefer for security reasons to get the update from Facebook and not from my client.
Ok after searching a log i found the solution
There are two primary methods through which you are notified of the outcome of the purchase, and a further method by which you can verify any payment information.
Firstly, Facebook will return details of the order via a JavaScript callback. The data sent to this callback includes:
payment_id, which uniquely identifies the transaction.
quantity, which indicates the amount of the item which was sold.
request_id, optionally, the developer can provide their own unique identification for the transaction when calling our Javascript SDK to render the payment dialog. This value is then returned upon purchase completion.
status, which indicates the current state of the transaction, i.e. 'pending', 'completed', 'failed' etc.
Secondly, Facebook will issue a realtime update notifying the developer that a new order has completed. The developer can subscribe to the payment_object callback to track order completions, using the payment_id as the unique identity parameter for each transaction.
Thirdly, at any time, the payment_id can be used to verify details of a transaction via the Graph API. Details such as the associated user_id, updated_time and amount can be queried, using the payment_id. The Graph API will also allow you to access further details including any refunds or disputes associated with the transaction.
If for some reason both the JavaScript callback and the realtime update fail and you do not receive the payment_id, we also allow you to query the Graph API using the optional request_id parameter, which can be specified by the developer when invoking the Facebook payment dialog.
please refer to:
https://developers.facebook.com/docs/concepts/payments/
and to:
https://developers.facebook.com/docs/howtos/payments/fulfillment/#rtu
Related
On an e-commerce site in the payment page I used the new js sdk from paypal.
When the user clicks on paypal button a popup appears and the user performs the transaction in the popup.
When the transaction is over the popup closes and a callback is called to do what is needed.
If the user manually closes the popup, a CANCEL event is emitted and the transaction is considered canceled.
The problem I'm having is that sometimes I see on the logs that I receive the CANCEL event (meaning that the user has closed the popup) but on PayPal account the transaction is succesfull and correctly payed...
Is it possible that the user closes the popup just before paypal sends the confirmation back or something like that? Anyone knows how this can be handled?
Using the JS SDK alone is for very simple use cases. For an ecommerce site of any importance, the JS SDK should be combined with the v2/checkout/orders API. This way orders are always captured from the server and recorded when successful, and things happening on the client side won't be relevant nor interfere with accurate payment tracking.
Your question doesn't give technical details for your current integration, but here's how to go about making a correct one from scratch:
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)
We are trying to integrate Paypal subscriptions with .Net web application done in Blazor.
We have created a button that allows the customer to enrol to a subscription defined in paypal business.
The customer can do the "payment" or "enrolment" successfully and it returns back to our web application with the specific URL that we defined.
This return URL contains just one parameter, called "token".
The problem is that we want to be syncronize paypal payments with our own control of payments implemented by us in the application, so we need to receive some other information in this URL like the transactionID or some identifier that we can use later to link with one customer.
We have configured paypal to support PDT.
When the customer finishes the enrolment to the subscription, the token returned to the URL i passed to our backend and with this, we try to get the some extra information.
We do a post to the url "https://www.sandbox.paypal.com/cgi-bin/webscr" passing as parameter the token that we received back from the transaction and our token as merchant in paypal.
Theorically, when doing this call, we should receive a response that contains "SUCCESS" and then, we should be able to extract some parameters configured in the PDT of paypal.
But, unfortunately, we always receive "FAIL"
Do you have any idea why does it happens?
Thank you very much in advance.
PDT returns are not reliable, as a payment can complete and the client return never happen for any number of reasons -- so PDT should never be used for anything important, and thus there is no reason for a well designed integration to bother attempting to verify them. Contents of a PDT is suitable for information purposes (display summary of success) to a customer only -- if you are doing anything else with PDT data, rethink your integration..
If you must continue such a very old checkout method that uses PDT as part of its process, a service such as IPN or Webhooks should be added on to receive a somewhat more reliable, direct post from PayPal with the payment information.
The best solution however, is to do neither of those things -- since adding on asynchronous notifications to an existing very old integration has its own disadvantages. Instead, discard your current integration completely as it's already about 4 generations old / 20 years old, and implement a new, current PayPal Checkout integration from scratch:
Follow the PayPal Checkout integration guide and make 2 routes (url paths) on your server, one for 'Create Order' and one for 'Capture Order'. Both of these routes should return 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 sending confirmation emails or reserving product) immediately before forwarding your 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)
I've never used PayPal before, it's not really popular here, and I'm confused by how the order and payment works. Can anyone explain it to me? I've read the documentation and I'm still confused.
To complete payer approval, use the approve link to redirect the
payer. The API caller has 3 hours (default setting, this which can be
changed by your account manager to 24/48/72 hours to accommodate your
use case) from the time the order is created, to redirect your payer.
Once redirected, the API caller has 3 hours for the payer to approve
the order and either authorize or capture the order.
I have created a working PHP curl call for this API in sandbox env according to the sample
https://developer.paypal.com/docs/api/orders/v2/#orders_create
The APIs I created before work like this:
Send a request to 3rd party payment
Get a response containing a checkout link
Redirect customer to link
Customer complete payment
3rd party send a request containing order and payment detail to a file/path on my server
My server receives the request and updates the order status/payment in my database
3rd party redirect the customer to my webpage
With PayPal, what I got so far is:
Send request containing order detail to /v2/checkout/orders
Get a response containing various links
Redirect my customer to the rel:approve checkout link
Log in to my sandbox customer account and pay using PayPal balance, click Continue
A popup message is shown: We're sending you back to xxx's Test Store to complete this purchase
The popup message is closed and I'm still at the same payment page with the Continue button as seen in the image
Send request containing order detail to /v2/checkout/orders
Get a response containing links
Redirect my customer to approve link
Step (3) is an old integration method, for websites using an old redirect-based flow. The preferred way to integrate PayPal uses no redirects. At all. Your website remains loaded in the background. Do the following:
Follow the Set up standard payments guide and make 2 routes on your server, one for 'Create Order' and one for 'Capture Order', documented here. Both routes should return only JSON data (no HTML or text). Inside the 2nd route, when the capture API is successful you should 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 sending confirmation emails or reserving product) immediately before forwarding your return JSON to the frontend caller.
Pair those 2 routes with the frontend approval flow: https://developer.paypal.com/demo/checkout/#/pattern/server
If, for some odd and inexplicable reason, you insist on using the legacy flow with a full page redirect instead of what I just described above, you must include a redirect_url in your orders creation request, so that PayPal has somewhere to return to after the order is approved. Immediately when the return happens, capture the order with an API call and show the success/failure result to the customer. If you want an intervening order review step before capture, you can do this, but you must also edit your initial order creation request to change the verbiage of the last button at PayPal from "Pay Now" to "Continue" so that the user is clicking on something that corresponds to what the next step will be. application_context.user_action needs to be continue for this change.
Capturing an order will return a v2/payments object which is the completed transaction with its own ID for accounting and refund purposes. (The order ID is only used during payer approval, and unimportant otherwise)
I had this issue too, and I eventually got a solution from the documentation.
You have to add application_context.return_url to your request.
Attached is an example in PHP:
$postData = [
"intent" => "CAPTURE",
"purchase_units" => $purchase_units,
"application_context" => [
"return_url" => "",
"cancel_url" => "",
],
];
You can make a whole lot of customisations to the PayPal Payment page by adding the Application Context option, For a full list of the possible customisations, you can check up the official documentation Application Context Documentation
I apologize in advance for this question, as its probably rather silly, but I really can not find any answers elsewhere.
My current goal is to integrate a subscription to my website, that allows for a user to have access to certain parts of the site.
I've watched a few videos on it, but it leaves me open ended with some questions.
PayPal allows you to manually create a subscription plan at https://www.paypal.com/billing/plans. When you create a plan here, it gives you the code you need to get the pay pal sub buttons to display on the page. Users can then use them to create the subscription. This is great. However, I have found now way to validate the results of the transaction. My goal would be that if the user was successful, I would be able to retrieve data via the API, that says it was successful, and I could then store than information in my database, and grant them access. Does anyone know how to get the data from the manually created facebook plans?
I did watch a video that had you do everything from your website (you create it all within your own code), the end result however sent everything through $_GET variables in the url. I feel like having this data exposed could result in the manipulation of the subscription, and grant it to users who were unsuccessful in creating a subscription.
I have no problem doing all of the coding to make this work, but I really want to make sure I do it the best possible way.
There is a few way to do it. By setting up a webhook and listen to paypal success notification and react to it. By using the Paypal Subscription API. Or a combination of both.
As you are using the paypal button you will have the onApprove function which will trigger upon user confirming the subscription. You can query the subscription data with:
onApprove={async (data: any, actions: any) => {
const detailedSubscriptionData = await actions.subscription.get()
// activate subscription on your side by sending it to your backend
...
// etc.
}}
Inside the data you have queried above, there will be a paypal transaction id (I-....) that is unique for each transaction, as well as your product id (plan_id). You can now do the following for verification on your backend:
Check if there is already a subscription (from another customer) on your side with that paypal transaction id
Check for the plan_id
Queried the API Subscription Details with the paypal transaction id and check for status, etc. as well as matching of plan_id
Keep in mind that for using the API you will have to queried for an access-token which in turn required you to have Developer App Setup following these steps.
We're currently looking at implementing Facebooks new subscription payments. We already have a working payment setup for Facebook, and the callback url is set correctly. If I make regular test payment the callback is called correctly.
The setup for testing subscriptions is according to this. But either if I choose the always success or always fail there is no callback made to the payments callback url.
It does return an object that says the subscription is active an has an ID.
{status: "active", subscription_id: 204626XXXXXX}
Is it possible you only get a request sent to the callback URL if the subscription state changes, and you already have an active subscription for the user? I would think you would get a client-side error in this case, but I don't see any evidence that there's an error code for that.
What happens if you make a regular test payment multiple times for the same account?
Facebook subscriptions are not regular purchase.
You will have to setup Real time updates on 'payment_subscriptions' object and listening to those available fields: ('status', 'pending_cancel', 'payment_status', 'last_payment'). See the documentation : http://developers.facebook.com/docs/payments/subscriptions/, there is a section called "Consuming Real time updates"
Each time an user subscribes or cancel (or an implicit renew), you will be hit with the related subscription id. You can then ask the Graph API about this subscription object.
You can also retrieve the list of subscriptions for any user via the Graph Api call on '/payment.subscriptions'
All these calls have to be performed with an App access token.
I must confess this process is quite annoying if you always performed "synchronous" purchases. I did implement subscriptions, this was a loooooong & painful travel ;)
Hope this helps
Subscriptions are mapped to OpenGraph objects on Facebook side, as well as virtual currency, so, I suspect there is no callback made to server side, all that you can do is make some kind of http post (through a form, for example) insde the FB.ui callback and implement the doPost method in a Servlet. That's would be a way to get subscription information into some data source.
Edit: concerning to payments callback, those items which order information are calculated based on OG object, facebook doesn't send a payments_get_items request, so there is no way to get order information after subscription creation. On the other hand, it could be possible that you receive some payments_status_update in the correspondent servlet (I'm talking about servlets because I'm a Java programmer, but the general idea applies for whichever technology you choose)