Searching for a while an answer to this basic question but I don't manage to find any answer.
I've created a web app in which user can subscribe monthly to get some features.
I've developed a bot which verifies daily if a user has paid and if it was successful.
So my questions are:
If a payment fail on 01-jan-2016. Will PayPal retry on 02-jan-2016? Or will it retry on 01-feb-2016? Or will it never retry?
In the object "agreement_details", there is a property "last_payment_date". If a payment failed. Is this property still updated? Or is "last_payment_date" updated only if payment is successful?
What is the behavior of "outstanding_balance" property?
Thanks a lot in advance for your answers
Related
Im working on moodle paypal enrollment feature. I saw that lessons were not getting enrolled to the student even after the successful paypal payemnt. Because the Paypal 'Payment review' setting was set to ON so all the payments are were in pending. I have turned OFF that setting. now I can see the payment complete.
but I do not see an option to accept the 'pending' transaction in sandbox/developer account as seller? Also when seller approves the payment will it trigger IPN simulator and update the payment status to my website?
When payment accepted manually will that call IPN url http://example.com.com/availability/condition/paypal/ipn.php for moodle lessons?
please help me
The Payment Review feature identifies high-risk transactions and notifies merchants of the review so they can hold shipments until PayPal has evaluated the transaction risk.
Yes, you will receive one more notification, when the transaction review will be resolved.
With status:
payment_status: Completed (If the transaction succeeded and the payment was accepted)
payment_status: Reversed (If the transaction failed and the payment was rejected)
You'll find all the notifications here:
https://www.sandbox.paypal.com/de/cgi-bin/webscr?cmd=_display-ipns-history
My understanding is that you just can't any more. I took this up with PayPal when they redesigned the Transaction Details screen because in the old version, there were indeed Accept/Deny actions as the help page that Ivan has provided a link to.
The support rep's response was "yes, this is an omission which I'll take up with development. For now, you can use the old interface, where you should find those options".
Now, that's probably 2 or more years ago (say 2019) and I haven't seen these Accept/Deny options appear in any transaction details page in the current version, and now there's no option to revert to the old version which did have them.
As a developer, I find PayPal's UI and feature set a set of moving goalposts that it's nigh on impossible to keep up with. I now can't even access my old support tickets to find out what the exact response was. I personally detest the platform.
This answer looked promising, but I found it confusing.
Does canceling a user subscription through merchant console/API refunds him money?
One person says:
Canceling a subscription will only prevent the recurrences from occurring and enable you to >refund the initial order price.
You can partially refund or fully refund each recurrence if you wish to reduce the fee.
with another user commenting:
Actually, no. Canceling a subscription for user will prevent the recurrences, yes, but this >will also refund user. Apparently, there is no way of canceling a subscription without >refunding. But you can refund without canceling, yes.
But the accepted answer says:
Ok. So, It's not possible to cancel a subscription from merchant console - you can only >cancel\refund individual transaction. Also, if you refund a customer he will receive a >message that his subscription will continue (true) and no refunds will be issued (false). And >you cant even send a custom messages.
So, canceling a subscription is ONLY possible through API call.
It sounds like if you cancel through Merchant console, then a refund is also issued. If you cancel through the Google Developer APIs, then no refund is issued unless you go do it in the Merchant console at the user's request.
Does anyone know if this is correct? We have removed a subscription from the store, and we still need to provide access to it but without renewing subscriptions so when everyone has expired, we can drop support altogether. Thanks for your answers!
I got a helpful response from Google Play regarding the exact effects of canceling an in-app subscription via Google Developer API.
In short:
Does it cancel auto-renew? Yes
Does it refund money? No
What happens when the cancellation goes through? An email is sent informing the customer that the subscription was canceled.
For more information, they pointed me to the following link (which is helpful):
https://developer.android.com/google/play/billing/billing_subscriptions.html#cancellation
I am implementing a payment subsystem with the REST API and recurring payments.
I have created several plans and when I make a subscription to one of these plans, the first payment it's done the day after I subscribe the plan. I expected to receive the first payment at the same moment I subscribe the plan. Why it's waiting for next day to do it?
At the moment I am using the sandbox.
Can somebody help me to achieve the behaviour I expected for the first payment when subscribe?
I mailed PayPal MTS and they answered me that for the moment it's not possible to do a inicial instant charge when you create a subscription using the REST API.
You can do it with the Classic API setting up the optional INITAMT from the Activation Details Fields.
You can get more details here: https://developer.paypal.com/docs/classic/api/merchant/CreateRecurringPaymentsProfile_API_Operation_NVP/
we test our application on PayPal sandbox.
I was able to make payment form one account (ewa.tkacz#zoho.com) to another (ewa.tkacz-facilitator#mmigroup.pl), and status of this payment is completed on payer account (payment ID 3F335538TV000622E), but on receiver business account I can't see this payment and can't get it by API.
This question is to PayPal, as You recommend to ask on Your forum on Stackoverflow, however if anyone faced similar issue, please vote or response.
I don't believe in what I see; it seems I make some stupid mistake... I wasn't able to find any such issue on Google, here and in PayPal technical support.
I have reviewed both test accounts and I see transaction 3F335538TV000622E (buyer transaction ID)/28A51825L7124154N (seller transaction ID) appearing correctly. There is a difference in the date for the two payments due to the default timezone for the accounts. Based on your screenshots, you are seeing the correct information as the transaction would show on 6/3/14 in the ewa.tkacz-facilitator#mmigroup.pl as it defaults to PDT and 6/4/14 in the ewa.tkacz#zoho.com which defaults to BST.
We're very close to launching our app and we want to test the dispute/refund process. We've made several successful test payments however we're hesitant to dispute them. Will our app get flagged? What is the best way to test the dispute/refund process?
They've listed all the documents for it here:
https://developers.facebook.com/docs/howtos/payments/disputesrefunds/
I'm sure if you put in the dispute reason "This is a test for the developer: please ignore" or something or contacted Facebook and asked them they'd find a way. There is though, at present, no public method of testing dispute handling.
While you cannot test the flow end to end, you can test the integration with your backend by manually executing a POST request to /PAYMENT_ID/refunds with an app access token and the amount to be refunded (could be total or partial). There is no need to start a dispute through FB to be able to refund it from your app.
If a dispute justifies a refund, you can award one using the transactions's ID and making a post to the /PAYMENT_ID/refunds with an ~app access token~ and the amount to be refunded [...] The dispute status will automatically be set to resolved with the refunded_in_cash reason.
A payment doesn't necessarily have to be disputed by the consumer for you to be able to refund it. If a user contacts you directly, you can issue a refund for the payment as long as the refundable_amount is greater than the amount you're trying to refund. This functionality is also helpful when you are testing your app.
Source: https://developers.facebook.com/docs/games_payments/fulfillment/disputes