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
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
I've been reading Stripe's api documentation (v3) and it's not apparent to me when to use Stripe's Invoice vs PaymentIntent objects. From reading the documentation, here's what I understand:
Stripe sees payment intents being the primary way of facilitating payments through their API going forward and Charges will be deprecated at some point.
Processing an Invoice creates a PaymentIntent under the hood and and initiates payment right away. What I don't understand is why is there no destination account field for the Invoice? If the Invoice is defaulted to be sent to the platform's Stripe account (this is an assumption I am making since there is no destination field), why there is an application_fee_amount field which is essentially the platform's "cut" of the transaction?
A PaymentIntent allow you to specify a destination account while taking an "application" or "platform" fee so you don't have to generate a transfer yourself.
A PaymentIntent and Invoice can be processed at time of creation or deferred until later in your payment lifecycle.
My use case requires me to conduct payments between two parties and take a "platform fee" for each transaction. I have successfully done this by creating a PaymentIntent and using the connected Customer account's credit card on file and populating the transfer_data field with the amount to send to the 2nd party involved in the transaction.
I started looking into Stripe's invoicing api since I am planning on building an invoicing solution for my platform and thought it'd be best to leverage what Stripe has to offer, but I'm failing to see a benefit for me to leverage it since I also need to keep track of transaction ids for the payment intents and taxes based on zip code (it looks like Stripe doesn't do this automatically so I might be out of luck here).
I couldn't find a way to get a transactionId for processing an Invoice but I see that the chargeId gets returned as part of the response when you confirm a PaymentIntent (https://stripe.com/docs/api/payment_intents/confirm).
So the questions I have are:
Why is there no destination account field for the Invoice? Does it automatically get send to the platform's Stripe account and require you to manually create a transfer?
Is there an easy way to get a transactionId from an Invoice?
Is there a way to get a transactionId when creating a PaymentIntent and setting the confirm=true so the PaymentIntent gets processed immediately?
For a platform that will have an invoicing flow and facilitate transactions on behalf of two parties, is it recommended to use payment intents, invoicing, or both?
What's the difference between a charge and transaction? When paying an Invoice, a charge id gets returned in the response but when paying a payment intent, a transaction id gets returned.
Thanks in advance!
You can think of invoices as subsets of payment intent, kind of the same way subscriptions are subsets of invoices.
What I don't understand is why is there no destination account field for the Invoice?
Actually there is one, but the field is transfer_data[destination]. Also, note that whenever an invoice is finalized, it will contain a payment intent, which is expandable, and with which you should be able to solve most of the issues you rose in your question.
To sum up:
Yes there is, as explained above.
Expand the invoice's payment intent object.
I'm not used to work with transactions, but I guess you could leverage their metadata to reference your invoice or vice verse to help you retrieve the need object in needed time.
As explained above, their is not dichotomy between those, if your invoicing your clients, the you should use stripe's invoicing system.
From what I see in the docs, transactions only concern purchase 'internal' to stripe, with issued cards. Charges are the attempts stripe will make to charge your bank account through the network, when a charge succeeds, the payment intent status is set to succeeded otherwise the payment intent might attempt more charges or stop trying at some point, and the payment intent will be set to canceled more about payment intent statuses here. In short payment intents are a subset of charges.
I hope this helped and didn't come too late, the answer might still be improve in the future, if others edit it or as I will learn more about stripe's issuing product.
I've making a SaaS that allows customers to subscribe to a plan, and use coupons at the checkout stage. The coupons give the customers X% off for X months, and by default, everyone gets a 7 day trial when they subscribe.
What is confusing me is the documentation. In one section it says that you should create SetupIntents to take a payment and elsewhere it says to use tokens.
I'm in the middle of coding the payment flow, but I just wanted to check to see if my logic and understanding is correct. Could anyone validate the below?
Customer enters card number and coupon
Call Stripe, get token for card
Send token and coupon to server
Create Stripe customer with token
Create Subscription with discount and pass customer ID
What has now happened is an authorisation attempt was made. If SCA is required, then the subscription status is incomplete and the latest invoice payment intent status requires action.
At this point, I can redirect my user to the SCA Flow using handleCardPayment() to prompt 3DS, and once complete the subscription status is then active.
If the invoice payment fails for any reason, then the subscription state is incomplete and the payment intent requires has a payment action required status. At this point, I should present my customer with the React Elements form again, and call the stripe.invoices.pay endpoint with the new card token
Going forwards, all subscription charges should not need further SCA approval, however if the customer changes plan or the bank requests it, then I can point my user back through the SCA Flow process
A diagram of the flow is here: Green is UI, Orange is Server, Blue is Stripe
Is there anything I have missed or misunderstood here? I've been reading about creating SetupIntents and PaymentIntents, but I'm not sure I need this?
If you are creating subscriptions using the Stripe Billing product they handle creating the PaymentIntent(if you are taking a payment immediately) or a SetupIntent (if you are setting up a trial or metered billing). All that you really have to do different is handleCardPayment (for payments) or handleCardSetup (for setting up trials and metered billing). This section in the docs is pretty good.
If you are not using billing they have a video on their Stripe Developers Youtube channel which may help clear up any confusion.
Hope this helps :)
Welcome fellow sufferer, cards and tokens are implemented in Stripe Charges API which is not SCA compilant. If you want use Stripe for payments inside the EU you should use payment intents.
Card tokens are also allowed for creating payment intents.
But if you want reduce the number of necessary authentications you should use setup intents (with usage = "off-session") for creating payment methods and not card tokens.
I have a lot of old customers who have still registered with the Charges API. I use the following strategy:
New customers always register via Setup Intents and Payment Methods.
Old customers use the Charges API until their tokens become invalid. Then they must also use setup intents and payment methods.
Of course, the customers do not notice much of it.
In summary, I would always use payment methods and setup intents for new customers and card updates. Only with the setup intents can you ensure that your customers have to authenticate themselves as rarely as possible.
EDIT: The crucial point is off-session payments that occur with subscriptions. The Stripe procedure is described here: https://stripe.com/docs/payments/cards/saving-cards#saving-card-without-payment
I'm looking for a way to charge my customer after a request was successfully accepted.
To explain it further. I'm developing a marketplace where a private seller can sell his products to private customers. But the customer can only "request" the product and only when the seller accepts his conditions a deal is made.
Now comes the question that I have. Is it possible that the user is paying for the request but is only charged when the request is accepted?
If a request fails the charge has never been done or gets a full refund (but without the loss of transactions fees).
I've seen some couple of websites that use credit cards for that case.
If you look at credit cards as a payment method they are usually a pull-based, reusable and synchronous method of payment. This means that, after capturing the customer’s card details, you can debit arbitrary amounts from the customer’s card without them having to take any additional action and there is immediate confirmation about the success or failure of a payment.
So that is why you can charge someone after a specific period of time.
But in Germany, we don't use credit cards that often. Only pushed-based transactions like Sepa/Sofort/iDeal. Would it be possible to "delay" payments with these methods?
This should be possible. I'm not sure what payment processor you are using/want to use or what is available in Germany but I assume this would be possible with many of them. Probably some useful things to search for that might be similar to what you want would be saving payment methods for later, managing subscriptions, and tokenizing credit cards.
Stripe for example allows you to save credit cards for later under a customer record and then charge a customer later. https://stripe.com/docs/saving-cards
Braintree has recurring billing https://developers.braintreepayments.com/guides/recurring-billing/overview and a vault for storing payment methods https://articles.braintreepayments.com/control-panel/vault/overview.
How can I tell from the stripe api -
A user has cancelled their subscription?
A user's credit card is no longer valid.
Is there anyway round having to call the stripe API every time the user logs in to check these facts?
Handling cancellations is purely the responsibility of your application—users don't have an interface to Stripe. If they're canceling, they're doing it through whatever account management system you provide. You should thus be tracking cancellations in your own database. Whatever database you're using, add a subscription status field and update it when a user cancels or re-subscribes.
As for tracking invalid cards, Stripe provides notifications of billing failures—and many other useful events—via webhooks. In most cases, if you're not implementing a webhook responder, you're working much too hard on your billing infrastructure. Stripe is built to push a wide variety of information to you; polling the API yourself is just overcomplicating things for most purposes.