I am working on Stripe's React Native SDK to accept payments on my App. It's working perfectly when I am trying to add a card and pay. In the process I am adding setup_future_usage to save the card (payment method) for future usage. But I am not sure how to charge the saved card in future.
In the Stripe docs, they have mentioned about off-session payments and the recovery flow in case the off session payment fails because it requires authentication but I could not find any information about on-session payments with saved cards.
I have the PaymentMethodId and Client Secret (from the PaymentIntent) but I am not sure how to confirm the payment.
PaymentMethods objects are designed for one-time usage unless attached to a customer.
In this particular case, you'll need to attach the PaymentMethod created from your PaymentIntent to a pre-existing (or new customer). You can then pass the pm_xxx ID to confirmCardPayment.
Related
So I am building an app with react-native (expo) where a user fixes appointment with some other person and to do so, he has pay the other person.
Now how can I handle payments here. What i want is the user makes the payment and the receiver should be the other person but how much i understood the payment gateways, the payment is received by the app owner or in simple words, receiver is a single person.
I also tried deep linking to directly take the user to some UPI app like google pay or paytm but it seems that those apps require some special type of account (merchant account) to make the transaction if we access them using deep links (which is a problem as it is not necessary that every user will have a merchant account).
As I said, it is always better that you have your own payment gateway account, and all the transaction goes through your gateway, meaning you get the money and you build a system which will forward the payment to the receiver. I have worked on 2 such apps:
1: Where we have our own razorpay account, and we get the payment first, and then we forward it.
2: Where in we were directly having transaction between 2 users, but not through app, instead we display them the account details of the receiver and give them 48hrs time to pay that account. But we had to manually handle this scenario since one cannot know if the user has paid to the said account, since it's not your account.
3: There is one more method where in payment gateway has a webhook which consists of a virtual account number, and every user that lands on your app, you can create a virtual account number for him/her and store the user-virtual account number relationship in your db, whenever there is a payment, you can find out about the user through this virtual account number. Read about this.
The deep link is a good idea, but again, as you mentioned, it will require the end user to be a merchant user(have a merchant account), you can find more details here
Maybe you can ask your users to create a merchant account, which again I am not sure if it's possible, and if it's possible, if it's feasible?
The best way according to me is, you handle this through your payment gateway, and instantly forward it to the user who should have received it. Again there are some rules and clause to it(some commission is taken by those payment gateway,etc), check those things out.
I think the most close answer to my question is to use razorpay routes where we can link multiple accounts with our account and transfer money accordingly.
More details here
I am working on a web app where I have user's stripe customer id. I have checked the docs and found that when we stores users card on stripe, stripe checks if it is valid and working for that time.
On the other hand when payment is made we can check it out if card is valid and working by the response from the stripe.
But in my case I have a flow where I payment is going to complete after the appointment is completed and I have to check if the card is working and valid before creating an appointment in database. If card is working we will create an appointment and if not then we will ask to user to add new card as previous is not working and after successful card addition we will proceed.
Unfortunately, there is no way to re-validate a card that is already attached to a Customer.
If you really want to validate a card again, you would need to create a new PaymentMethod with the same card and attach it to the Customer.
I am currently upgrading an old system writing in JSF, which communicates with Paypal to create an "Acceptance term" for recurring payment, it generates a Token and when the client accepts the term, it creates an Agreement Id, later we use these to charge the client based on the services he used.
On the Paypal developer website, the Billing Agreement API is marked as deprecated, so I can´t work with it, they offer the Subscription as an alternative, but it doesn´t give the Agreement Id or the possibility to charge the user based on the usage, at least, not that I´ve seen.
Is there a way to create the Token and Agreement, or to use the Subscription (or other methods) to charge the user based on that?
eg. We offer a mobile plan for U$ 10, plus U$ 5 if the user sends more than 1000 messages, we first check if that happened, then we charge the user.
If the account is approved for reference transactions, and it sounds like it may be, you can use the Vault API which is in open beta, in conjunction with the orders API. See this example.
I'm trying to build up an android platform that takes in user credit card info and charge it on use without inserting the credit card details after saving one. But I don't seem to actually see any possible work ways in the "In-App Payment" SDK and I think I see it under Square's java SDK. But as researched in github, their official reply is that I'm unable to use java SDK in android app.
So I'm trying to figure out has anyone done this before or face the same issue?
In-App Payments SDK is solely meant for generating a card nonce on your mobile application. All other API endpoints must be done on a server or service due to security reasons (you don't want to store your personal access token within your application). Once you have that nonce, you need a server or service running that your mobile application will talk to. Ie the most basic is passing the nonce to the Charge endpoint to charge a customer.
On that same note, we have another endpoint called CreateCustomerCard, which you can pass the nonce as well as customer_id to in order to save the card to this particular customer's profile. So, at the very least you'll need to create a customer in order to have their id.
For info around saving cards on file, see this post: Hot to generate card nonce for repeated transactions without making users to enter card details?
I would like to make an API call to Big Commerce backend to complete a purchase on a customer's behalf. Based on the API reference:
https://developer.bigcommerce.com/api/stores/v2/orders#create-an-order
By default, I believe that one can only create an order that not yet paid by the customer. Please correct me if I am wrong.
So, my question is - How do you make a payment on behalf of a customer for the order? It is safe to assume that we have a tokenized credit card of our known customer in a payment gateway like Stripe.
My guess of how it could be done is when an order is created, I can set up a webhook to call the payment gateway to make a charge on the customer's credit card. Is this correct? Are there anything that I should watch out for?
Currently, you cannot use the BigCommerce API to process a payment or full transaction. We only allow payments through the control panel where you can enter credit card details or on the storefront made by the customer. If you'd like to make use of tokenization or recurring payments, it is better to use Rebillia or Recharge (apps).
As you stated, you would need to make a call to Stripe's API to charge the card on file with the customer's token. This should be fine. It won't make any calls back to BigCommerce, so I'd be mindful of error handling (such as if the card has expired) and how you'd retry or mark the order in BigCommerce. Depending on how it was configured, you would want to check order details to ensure you were only processing payments from API created orders.
I'm not sure of what PCI implications might be for the storage of the Stripe tokens. That would be another point for consideration.