we are dealing with heavy chargebacks and refunds. But I am unable to identify how can I get the details of chargebacks and refunds. We have published our game through third party so they own the Company Account for transactions. We have asked them, but apparently they don't have anything to help us out. I have used Graph API to log the transaction details and I have also used the debug tool to find out the reason or details of chargebacks and refunds. but even our refunds does not have any reason attached with it. Please help me out of this. I have done alot of Google on this but i am unable to find out what I need to know
Regards.
All you will actually get is a “Refund Reason Code” – which of these there are, and how to access them, is described here:
https://developers.facebook.com/docs/payments/disputes/#refundcb_tracking
Edit:
It does not look like you can look up the refund reason code via the API – but Facebook will send it to you, via a ping to your callback URL:
“If the order has been refunded by Facebook, we will ping your callback with a payments_status_update for the order in questions with a status of refunded. In addition, there will be an additional field returned called refund_reason_code with one of the following values: […]”
So you will have to react to that and evaluate the refund reason code (save it to your database, …) in this callback.
Related
Hey I would love to learn an know how payment gateways are implemented I have been google searching for code examples to implementing PayPal to a MERN Ecom project but I really could not find any examples on this
Can you please refer me to link where I check that up and if possible please you can make just a basic snippet on how this can be implemented I would really appreciate it
This is the kind of implementation I would love to have
Take in the customers Personal info i.e Name, Email and all necessary info etc
I would love to collect a shipping address
I am not sure what about approaches to implementing a server and client side confuses, but below is some documentation to review. The samples are in standard node.js and JavaScript, so no express or react details are considered. Make your own adjustments to use with express and react.
On the server, two new routes, one for "Set Up Transaction" and one for "Capture Transaction", documented here: https://developer.paypal.com/docs/checkout/reference/server-integration/
A client-side approval flow to connect to the above, documented here: https://developer.paypal.com/demo/checkout/#/pattern/server
By default PayPal collects and returns a shipping address, so it will be available to you inside onApprove on the client side, or via an additional API call you could implement to get the details before going ahead with a capture, or simply in the final response of your order capture API call
When you capture an order, there will be a payment object with an ID. That is the PayPal transaction, and what you should persist in a database, and also what would be referenced for any refund. (The order ID used during approval and any debug_id of the response can be kept around for logging purposes, but have no accounting or reporting value)
I'm using ASP.Net Membership Provider for logging into the premium content of this web site. The content isn't downloads, it's web pages of information and discounts, etc. That part is done. We want them to also have a PayPal Subscription annual payment to see the premium content. I would like ASP Membership and PayPal Subscription to work together as much as possible, but for the minimum I am thinking they will have to create a MemberId before they pay. Then I will send that MemberId to PayPal to associate the two.
I think I can do that like this:
Set "Auto Return" on in the interface so that it will redirect to return URL when payment is made.
Set "return URL" query string to MemberId. This requires not using the precompiled "Saved" buttons. I'll have to set it in Code Behind with Name Value Pairs, "NVP" to PayPal. I was hoping to just paste the stupid button.
But then, there were those "Advanced Variables" in the Button maker. Problem was they are compiled into the Saved button, so I can't change them for each person. But maybe that one parameter could be separate from the compiled parameters? Is this better than hacking the return URL? Are "Advanced Variables" good for anything?
All the details about the transaction will be POSTed to the return URL if I put in the right code, which might be rm=2. (Right?) Then I can record it.
This process is said to be unreliable, though, and PayPal recommends using a secondary system that they have, "IPN". PayPal sends the transaction details to me. I send them back http 200 code. Then I send it back to them in the same order I got it. Then they send me http 200. Then we all know it's good. This sounds like a few hours research to me, but if you've already done it once, it sounds like copy and paste. I hate reinventing the wheel. Is there a .Net sample of this IPN handshake/dance?
Also, if I do the IPN thing, maybe I don't need Auto Return. Maybe I add MemberId to "notify" URL instead of "return" URL. Then PayPal can handle the confirmation page, email, etc. Is that better?
Assuming we get the Subscription paid for and recorded with the MemberId, at least once per user session, after they log in, I have to check if they have paid their PayPal subscription and if it's up to date. "GetRecurringPaymentsProfileDetails" does this, but it is an API operation. That makes sense, but I was hoping to avoid learning their REST API. (Is there a "NVP" version?)
REST API OAUTH tokens expire every few minutes, but the only way it tells to get one is by using "Bash" to "cURL" some Linux commands. Again, this seems like the kind of thing that would only ever have to be written once. Does this already exist as a sample code somewhere?
(I don't want to use the API to do the Subscribe, because I don't want the Credit Card numbers to ever go to our site. Too much liability. That's why I wanted PayPal.)
Will this even work? I know PayPal has 18 ways to do everything and they all exclude each other, and I'm just getting the feeling that I'm creating a patchwork of unrelated ideas to fool myself into believing there's a light at the end of the tunnel. I've already been researching and experimenting for 10 hours or so. I really thought, going in, I'd just be pasting a stupid button.
If you want to just "copy the stupid button" then you'll have to stick to Payments Standard, and then you'll be limited with what you can do. For example, you won't be able to use GetRecurringPaymentsProfileDetails for a standard subscription.
Instead, you'll need to use Express Checkout and / or Payments Pro. There is indeed an NVP API available for these, and there is also a SOAP/XML version. Details on those can be found here: https://developer.paypal.com/docs/classic/api/
Specifically, for Express Checkout, you'll want SetExpressCheckout, GetExpressCheckoutDetails, DoExpressCheckoutPayment, and CreateRecurringPaymentsProfile. Some of those calls are optional depending on how exactly you're configuring things with the checkout flow.
For Payments Pro you'll use either DoDirectPayment / CreateRecurringPaymentsProfile or PayFlow depending on what version they put you on.
In any case, IPN is definitely the way to go for post-transaction processing.
.NET IPN Sample - https://github.com/paypal/ipn-code-samples/blob/master/paypal_ipn.asp
My question is simple yet I can't find any SO posts or PayPal documentation to answer it.
In the event of a PayPal user having some error being redirected after completing their checkout (internet goes out, browser crashes, they close their browser before the redirect goes through, random networking issues, etc.) How are we suppose to handle that?
I thought using the following REST API
GET /v1/payments/payment/<Payment-Id>
Would solve my problem but since the state returned from this request does not change from created to approved until the funds have been executed it is useless. In the case of having some redirect error you will not have been able to execute the funds and thus it will simply be in the created state still which does not help you.
Additionally I thought maybe PayPals IPN system used for CLASSIC API would be the answer to my problem but again it fails. The IPN system does not contain relevant information such as transaction ID which is needed to link the two systems together.
Is there no way to do automated error handling using the REST API?
Paypal provides access to a parameter called "SoftDescriptor" in a number of their payment request API calls, in the classic API (either NVP or SOAP). In theory, this parameter lets you send transaction-specific data along with your request, which will be passed along to the buyer's credit card statement.
This parameter is available on at least:
DoCapture
DoReferenceTransaction
DoExpressCheckoutPayment
I cannot, for the life of me, get this to work. None of these calls seem to set the softdescriptor for the initial descriptor (Which shows up in the bank statement while the charge is pending, before the payment posts). I've been waiting a few days for the payments to post to see if it will change at that point, but I'm skeptical.
Has anyone successfully used the SoftDescriptor? Did it require extra account setup?
This might be very late.
Soft Descriptors is supported only for US,UK and CA merchants.
Your account needs to be enabled for Soft Descriptor.You can contact Businesss/Customer Support to get this enabled.
https://developer.paypal.com/docs/classic/release-notes/merchant/PayPal_Merchant_API_Release_Notes_115/#softdescriptorforpro
Sorry, I know this is an old post, but I was looking for the same answer to the same question and I thought I would share what I found.
You should be able to use the following link to move past this error. In my case, I had a comma after the wrong right curly brace. Just copy and paste the example, in the aforementioned link, and change the values to meet your needs.
And I am about to post my own question about why the transaction amount is considered invalid
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)