I am using the PayPal rest API recurring payment.
About Agreement Transaction, it has many states i.e.: Completed, Expired, Pending.
What do they mean and when they appear?
Completed – successful payment, done and confirmed. Expired – recurring payment that has ended. Pending – payment that needs confirmation (or is checking at the moment)
Also you can read this FAQ https://developer.paypal.com/webapps/developer/docs/classic/products/
There are a few moments with account settings (like currencies f.e.) you should set to minimize the pending time. Hope that helps.
Related
Before migrating to the Payment Intents API the user's credit card payment was confirmed and charged on the server side using the token (received from stripe.createToken) after the purchase has been completed. This gave us the possibility not to confirm the payment in case any errors happens.
Now, with the Payment Intents API the payment confirmation happens already on the client side (stripe.confirmCardPayment) which is a problem in case an error happens on the server side while completing the purchase as the credit card has already been charged. A refund is not valid solution your Stripe fees won't be refunded.
How can we implement card payments with the Payment Intents API but confirm the payment at the final end of the purchase (as in the legacy workflow)? Or how can we prevent the credit card from being charged in case an error occurs during the checkout workflow?
Unfortunately, we couldn't find a solution to this problem in the documentation.
Help appreciated!
Here are the docs: https://stripe.com/docs/payments/payment-intents/migration
What you are looking for is modeled via "manual confirmation" of a PaymentIntent: https://stripe.com/docs/payments/accept-a-payment-synchronously.
It isn't Stripe's recommended integration. The recommended approach is to confirm client-side and listen to webhooks for payment confirmation.
This is because with manual confirmation, there is a higher chance of customer "drop off" where they authenticate your PaymentIntent on your webpage but close it out, meaning you lose your client->server roundtrip, leaving your payment unconfirmed (eventhough the customer thinks they authenticated hence paid).
Additionally, manual confirmation only works for card type payments, it is not supported for other payment methods based in other regions like iDEAL or SEPA Debit etc.
In our case, we wanted to authenticate the card payment at the end directly after making the charge. The Stripe support was able to help us with the following answer:
As I understand you would like to authenticate the payment at the end directly after making the charge. There is a solution to this, with the capture_method being set to Manual - https://stripe.com/docs/api/payment_intents/create#create_payment_intent-capture_method. What this would mean is, that the charge will be made and the user / client would be able to confirm the payment afterwards in the Dashboard directly.
This method is called Auth and Capture. Place a hold on a card to reserve funds now but only capture them after your business completes the service. When a payment is authorized, the bank guarantees the amount and holds it on the customer’s card for up to seven days, or two days for in-person payments using Terminal. You can find more information along with the API's under this Link: https://stripe.com/docs/payments/capture-later#authorize-only
Our application has different plans (Basic, Advanced, Pro). We use Stripe.
Each Plan gives you X amount of credits per month.
We credit each
Customer with the credits when he has made a successful payment
either by subscription creation, subscription update, or subscription
cycle.
The Customer is only credited on successful payment; we listen for the invoice.payment_succeeded webhook on our server and credit the user in our database.
The problem we face is this:
Customer attempts to use some credits. We detect that he has no
credits nor a Plan.
Customer is prompted to sign up for plan.
Customer provides payment details.
Customer authorises 3DS on the client via stripe.confirmCardPayment(). He's informed that payment went through.
Customer attempts to use his credits. At this point the webhook invoice.payment_succeeded
event did not arrive on our server to update our internal Customer and credit him his
credits (or mark his subscription as active). So the user is still blocked from using our application. He's notified that he
doesn't have any credits.
We eventually receive the webhook that payment has gone through and we update the
customer subscription and credit his credits.
As you can see step 5 is problematic. The customer has paid however when he tries to use his credits he is informed he doesn't have any because the webhook that will credit his credits has not arrived yet on our server.
The webhook will arrive within the next minute or so but in the meantime the Customer is baffled that he paid for credits yet when trying to use them he's informed he doesn't have any.
How would you handle this?
Possible solutions
Client sends HTTP call to credit his account
When stripe.confirmCardPayment() succeeds, send an HTTP call from client -> server to credit the user.
This solution is both insecure and error prone.
It shifts the responsibility of crediting the user account to the client. Nothing would stop the client from sending forged HTTP calls to credit his own account.
If the user closes down his browser immediately after stripe.confirmCardPayment() succeeds, the call to credit his account would never reach our servers.
Client polls server to query successful completion
Every invoice.payment_succeeded event gets processed on our server and saved in a table successful_invoices.
When stripe.confirmCardPayment() succeeds we poll our server to find out
if a successful invoice with the invoice_id exists in that table.
If it does, we hide the loading screen and tell the client that his payment was processed and his credits have been credited successfully.
This is our preferred solution for the time being.
This is something we have faced already in various payment gateway integrations. You have to wait for the webhook to confirm the payment.
Then there needs to be a backup event that requests the gateway to confirm if the payment status is successful and so you can update the same in your records.
Normally, the webhooks do the needful else your payment_create event from your app can request that provider to check the status. But there is a mild chance of this not getting update unless you put a delay to check this post payment_create.
We tried adding a CRON that checks the status of the payment made in last 1 min. All payment having pending status from last run are picked status is updated from gateway provider. BUt in this case you need to be sure that no record should have a duplicate run in form of event from payment create and added to cron as well at same time.
I am growing frustrated with the lack of features and poor documentation of the Google Wallet for digital goods subscription API.
My question is the following:
If Google wallet sends a postback to my URL, and I do not acknowledge the payment (send status 200), does the payment get refunded or not appear on the card statement in the first place?
It seems rather strange that there is no way to programmatically cancel subscriptions. A work around would be to manage subscriptions on my end and only accept the postback payment if their subscription is valid. This would of course be frustrating to a user if they canceled a subscription, yet they still see a charge to their card and then a refund. I would like to avoid that.
Thanks in advance again everyone.
I'm not a Googler so this is subject to being crucified :)
To get an official response, it would be best to contact Google directly - you should see a "HELP -> Contact Us" in your Wallet Merchant Center.
Important: If you specify a postback URL, your server must respond promptly and correctly to the HTTP POST messages that Google sends for each transaction. Otherwise, the transaction will be canceled.
REF: Official documentation on handling postbacks
This somehow/probably relates to the old question in credit card processing of the difference between an AUTHorization and an CHARGE (aka "capture").
An AUTH for x amount would need to be sent for processing. Otherwise, how would Google send you a positive result for the transaction (aka Google would send you a postback after such successful "Auth" transaction for x amount - re: does account have enough funds to cover x)?
So there would be a "pending AUTH" for x value on card holders' account, subject to "capture" (finalizing, turning that AUTH into a CHARGE) at some later time (perhaps after you successfully acknowledge the postback).
What Google does (e.g. "Void" or "never capture") to that pending AUTH if you don't acknowledge (aka "...transaction will be cancelled"), or whether or not the above scenario is actually what occurs in Wallet for Digital Goods, can only be answered by Google. The above is only a personal (mine and mine alone) insight to standard credit card processing...
Hth....
I'm moving my site's payment processing from Google Checkout to Google Wallet (Digital Goods API), but I'm running into an issue involving payment notification. My goal is to only send licenses to customers after orders are charged, but I don't see how this is possible.
Right now I'm sending licenses to users when I receive the postback JWT, but this isn't the behavior that I want, because, according to my tests so far, it takes about 30-60 minutes to actually charge the customer after the purchase (until then, the order is in a CHARGEABLE state). This is a problem because I've frequently had orders be cancelled before they are charged - I obviously don't want to send out licenses when this happens.
So my questions are:
1) Why aren't customers charged immediately? According to the documentation, "Google Wallet for digital goods orders are charged automatically", but there's no explanation of the delay.
2) Is there any way to receive a notification after the customer is charged? The postback and the success callback that are described in the documentation are both no good for this, because they're both triggered when the order enters the CHARGEABLE, rather than CHARGED state.
I'm hoping that there is some system like the Google Checkout Notification XML API, where different notifications are sent out at each stage of the purchase process, but the Google Wallet documentation makes no mention of such a system.
3) On a related note, is there any way for me to get email notifications when orders are complete? Google Checkout did this, but Google Wallet does not seem to offer this option.
3.) I suggest you send yourself an email through the success_handler via javascript. I'd probably use and ajax call like jQuery's .post and pass all the values such as order ID and so on to a php file and send the email from there.
https://developers.google.com/commerce/wallet/digital/docs/jsreference#successhandler
1+2) Here's how I understand it: CHARGEABLE means the credit card has been authorized, and whatever needs to happen between the banks and all that is in progress. CHARGED means google has actually received money from the banks. So the explanation of the delay (I believe) would be the same as if you buy something at the store with your debit card, then look at the account statement and the charge still is in there as "pending". I am under the assumption that you can pretty much rely on the CHARGEABLE state and consider it paid. Whatever happens after that is probably the same risk as when someone used a fraudulent credit card, and the charge gets returned later, or the customer disputes the charge on their statement.
How did your customers cancel the charges? If that happens, could you revoke the license?
I want to provide recurring facility to buyer (customer) so suppose I have set the 5 recurring cycles for my product. Now I want to maintain my database also which contains all the transaction details , but when the recurring payment will occur, I can get only email from PayPal about the "Transaction Successful or Failure".
Can anyone tell me how can I get that transaction confirmation or failure details data to store in my database ?
This will vary depending on how the API of your payment provider works. Most payment gateways and third party processors offer some kind of notification service to alert your website as to when payments are made and transaction information. Paypal's IPN and Authorize.Net's Silent Post are two good examples of this.
Disclaimer: I am the author of that article on Silent Post