I am trying to connect Authorize.net payment to the website.
My goal is to create a crowdfunding function for the website.
And I can't found a description where Authorize.net says how long it keeps Customer Payment Information, which I save through the Authorize API and getHostedProfilePageRequest method.
How long does Authorize keep Customer Payment Information?
I have found the answer. The support team replied to me.
Here is their answer:
CIM profiles would be saved around 2 years after the card expires. As
the card can no longer be used after it expires, it's worth deleting
the information since it's no longer valid.
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'm trying to register a user payment info by directly using fetch to Stripe's API (since it's a React Native app, I can't use Stripe Elements). It follows the usual concept: a user registers his credit card, which is then associated to his account so he can make payments in the app.
I tried to approach this problem by creating a credit card token with the info that the user provides on signup, but I've realized that that token is only worth for one payment, or for associating to a customer.
Meanwhile I saw that Sources are maybe what I need in my app, since we can get back to it and charge it multiple times. However, from what I see in the API docs there's no reference to the credit card info when creating the source.
What do I need to create to be able to do this (registering a card to be used several times) only through the API?
By creating a token previously, you can then use it as an argument to the creation of the source. Then, the token properties will override source parameters. Thanks to #Evgenii Malikov for the tip.
You need to create a token of your card previously. For that, you can use tipsi-stripe package.
Perfect package if you want to implement credit card, apple / google pay.
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
How do I save a card to a customer with Stripe.js?
I don't want to change them at this point. I just want to save the credit card info to their stripe account so I can use it later.
It seems like I'd need to use createToken from Stipe.js. But my understanding is that this is a one time use token. I want to save the credit card info for later use.
This seems to be a similar question: Stripe Payment: Save token and customer and make payment later from token
but the solution isn't clear. I'm not sure if it means for the customer I need to save card=token and everything will work fine.
Though the question is an old one and solution of this problem is now pretty straightforward in the current Stripe API, I'm just answering for those who accidentally reached or will reach here without reading the Official Stripe Doc properly(like me) searching for this question.
To make a stripe payment You first need to make a call to the Stripe API(Using Stripe's Checkout widget, Elements or Mobile SDKs) with the User's card information. As a response, you will get a token. Then you can charge your customer immediately using Stripe's Charge API. This is for just one-time payment. You will find an example here.
If you want to save customer's information for later payment, you need to create a 'Customer' first using Stripe's API and then using that customer's ID (returned as a response from the previous API call) you can charge this customer. Example here.
I just described the process briefly to show the idea at a glance. But you should really need to read this quickstart guide in Stripe's documentation. This explains the process very well.
I just want to save the credit card info to their stripe account so I
can use it later.
Then that's exactly what you can do!
If you're already passing the token back into your server-side code, you just need to update that server-side code to retrieve the customer and create the card on that customer record using the token.
Not knowing what language you're using I can't provide relevant sample code, but the Stripe API reference has functional examples for Ruby, Python, PHP, Java, and Node.js.
Note that if the customer has any outstanding invoices, this card will be used the next time they attempt to settle—so while simply adding the card won't create a charge by itself, it's possible the card may still be billed.
A key point that the prior answers seems to dance around but do not explicitly state is that you can't simply save the credit card (token) in Stripe. Stripe's API's don't save credit cards per se, however, they can save a customer and attached to the customer you can save one more credit cards (or payment sources). So a credit card (or payment source) is not a stand alone entity in the Stripe storage system, it's a child entity of a Customer.
I’m integrating authorize.net into my web application. I’ve used the direct post method (DPM)to charge the account initially. However, for each transaction I also need to set up automated reoccurring billing. How would I go about doing this without asking for the information again, particularly when after DPM posts the initial transaction, the credit card data is no longer available?
I also would like to get the status of each reoccurring transaction so it can be confirmed and followed up on if necessary.
You can't do that with DPM as it takes the user's credit card information off of your website so you don't have access to it. If you want to make an initial payment and then use ARB to create a subscription you need to use AIM with ARB.
You need to use the ARB interface in order to do recurring transactions but there are a lot of problems with it, like lack of support (send an email and wait a couple of weeks for a non-helpful response for example) and weak documentation.
Documentation for SOAP interface for Authorize.net ARB:
http://www.authorize.net/support/ARB_SOAP_guide.pdf
And for the XMl interface:
http://www.authorize.net/support/ARB_guide.pdf
ARB programming documentation:
http://developer.authorize.net/api/arb/
I just switched off of Authorize.net to USAEPAY. Here are some reasons why:
1. When you use Authorize.net ARB, your customer comes on the site to sign up, and you send the ARB request to create the subscription and you get back a success code so you give the user the subscription. Then later that night they actually try to collect the first payment and a lot of times this fails, so you get a spreadsheet emailed to you the next day about the problem. This is terrible because now you lost the opportunity to say to the customer at sign up time that the card is declined. Goodbye sale!
2. I don't know if they added this recently but they didn't have a way to verify if a customer's credit card is still valid. Imagine 3 months into a subscription the card is over the limit, or cancelled, or expired etc. You don't know so how do you prompt the customer to put in a new card? You just stop getting paid, unless you want to manually open these spreadsheets and start emailing customers. YUCK.
USAEPAY works much better, the API is easier, its much better documented and you get email responses in 1-2 days and its less expensive. For example, you can query USAEPAY to get a list of successful payments, and verify that you shouldn't deactivate the account for non-payment:
http://wiki.usaepay.com/developer/soap-1.4/methods/getcustomerreport
Before you go too far with AuthNet I highly encourage you to save yourself a lot of pain and contact FranchisePaymentNetwork (FPN) to get set up with USAEpay.
They can even POST BACK to your website to let you know if a transaction is successful or not for recurring billing transactions and you can query it to verify that customer payments are getting collected so you know if you should expire an account or not.
I am not affiliated with USAEpay or Franchise Payment Network except as a satisfied paying customer / consumer of their services.