I'm receiving a confirmation token after successfully paying through the Stripe API.
I'd then like to give paying customers access to an API endpoint, which they'll query to receive data. But only paying customers should be successful in querying the API. So how should I think about doing this? I'm entirely new to online payment systems.
I was thinking like this:
User -> Stripe -> Payment confirm -> Payment token
User -> Send token to endpoint -> Check token is valid? -> Return data if so
Is that right? If so, how would I check the token? I thought Stripe might have a way to verify a token. Or should I build my own db for this purpose?
My app is running in Node and Express.
Access to the service should be handled wholly in your own system, you could do this by associating a particular payment with a customer in your own database. If the customer pays at Stripe, then you could be notified about that via a webhook [1], and then you could "turn on" access for the authenticated user for example.
How you associate a particular payment with customer can also be handled in your system, for example, creating PaymentIntents and then saving them mapped against your customer in your own DB.
[1] https://stripe.com/docs/webhooks
Related
We are using Stripe subscriptions to handle payment for a SaaS application we are building
Currently, our development team has implemented the following logic:
User enters card details into Stripe elements UI as the final step of signup to our app.
If the credit card is deemed valid by Stripe Elements, the signup process to our app completes successfully.
A stripe customer & subscription is created.
Our server processes the webhook from stripe to confirm if the initial payment succeeds/fails
The problem we have is that the customers card isn't being charged until after the signup process to our app is complete. In some cases this results in a poor user experience, where the user is told by our signup process that they have signed up successfully, then they receive a 'payment failed' email from our software if the stripe charge doesn't succeed.
What is the best way to handle this signup flow? Since we are relying on the stripe webhook to tell us if the charge has succeeded - a suggestion has been made that we could monitor for the webhook response (eg. every 1 second, in a loop) and confirm payment has succeeded before completing the user signup for our app. The flow would then become:
User enters card details into Stripe elements UI as the final step of signup to our app.
If the credit card is deemed valid by Stripe Elements, we create the stripe customer / subscription
Monitor (in a loop) for a response from the Stripe webhook to confirm if payment was successful
The signup process to our app completes successfully (if charge is successful), or fails if the charge is unsuccessful.
This also seems like a bandaid solution - what is the best way to handle our issue?
I have noticed there is an option to use 'pre-authorisation' of a card, but I'd prefer not to go down this road if it leads to extra items on a customers bank statement.
This seems like something that would be very common - we would greatly appreciate any advice
Thanks
The most straightforward solution seems to be that your integration isn't waiting for the payment to complete.
With Subscription, you can wait synchronously on your backend for a status: active on your backend, before returning a response to your frontend. You don't even need to poll for the webhook response, cause your backend creates a Customer, creates a Subscription, and returns that response to your frontend, to show an error or success.
(waiting for webhooks is good but when your integration is manually starting the Subscription, you don't necessarily need webhooks)
From the frontend perspective, your user sees a loading spinner, until your backend is able to say "payment successful, you are signed up!"
How can I use Stripe Connect, let's say to create a "Direct Charge", while sending an Invoice on the Telegram Payment API?
The Telegram API seems to only allow for a "provider_token", I see no further details for the Stripe API, like the required "stripe_account" property for direct charges.
I guess Telegram itself uses Stripe Connect to charge on the users behalf... But that doesn't seem to have stopped this guy from doing something very similar:
https://www.reddit.com/r/TelegramBots/comments/6f6b4z/telepay_a_bot_that_enables_instant_and_secure/
He uses express accounts, but the fundamental problem of not being able to speak to stripe directly seems to be the same.
Thanks :)
You're correct about the Telegram API: there is no way to create a direct charge to a connected Stripe account when receiving payments through Telegram. But there are workarounds. I'm the author of the bot you linked; here's how I managed to move funds from my account to a connected Stripe account via Telegram.
Firstly, you need to accept the payment as usual (e.g. follow the normal sendInvoice flow). For my purposes, I made the payload parameter the ID of the user that is being sent the money (it's later matched with the Stripe account ID in the database, but you can do this however you want). The rest is out of scope of the question, so I won't describe this process in detail; Telegram has a very nice guide on it.
Once you receive the successful_payment event from the Telegram API, you can then transfer the money from your own Stripe account to the linked Stripe account using the Stripe Connect transfers endpoint, but be careful: it doesn't give you the amount that was given to your own Stripe balance (taking fees into account), so you will need to calculate that yourself. Depending on your account, it would look something like this for JavaScript: payment.total_amount - Math.round(payment.total_amount * 0.029 + 30).
After you've transfered the money to their account, you can perform a payout as usual with the payouts Stripe Connect endpoint.
But note that this is just one example; you can use all of the Stripe Connect APIs with this. In fact, you probably have even more flexibility with this, since the funds hit your Stripe account before they reach the connected account's, so you can do whatever you want with them :)
So, TL;DR: Once you've received the successful_payment from Telegram, transfer the money to the connected Stripe account, then perform a payout on it.
I am working for the first time with Stripe. I am using stand alone accounts. I have a platform account also. In my web site a number of people with different Stripe accounts will be opening up campaigns for which money can be donated by various donors. Each campaign owner has a separate stripe account and the platform will be charging through the campaign owner's stripe account.
So what it amounts to is the platform account will be charging for a number of campaigns through each campaign owner's Stripe account. My problem is related to web hooks. One point to remember is each campaign has an id associated with it in the database and I am storing the API key of each campaign owner's stripe account and associating it with this id. To get Stripe data from the web hook in the web hook end point I have to set the API key of the connected account with a statement like:
\Stripe\Stripe::setApiKey("api key of stand alone account");
$input = #file_get_contents("php://input");
The trouble with this is there is one web hook end point for a number of Stripe accounts. I cannot hard-code the API key in the above statement. I have to fetch the appropriate API key from my database using the id.
But when Stripe invokes the web hook end point I simply do not have the campaign id with me in order to fetch the appropriate API key and set the API key. Is there any solution around this?
You don't need to store each account's API key. The only information you need to store is the account ID ("acct_..."). With standalone accounts, your integration will receive the account ID in the last step of the OAuth flow, in the stripe_user_id parameter.
You can then issue API requests on behalf of this account by using your own (the platform's) API key, and the Stripe-Account header.
Regarding webhooks specifically, events sent to your server via a "Connect" endpoint will include a user_id field with the account ID. So you can do something like this:
\Stripe\Stripe::setApiKey("PLATFORM_API_KEY");
$input = #file_get_contents("php://input");
$event_json = json_decode($input);
$user_id = $event_json->user_id;
// if you need to send an API request on behalf of this account,
// for example if you want to verify the event by fetching it from
// Stripe, you can use the Stripe-Account header:
$event = \Stripe\Event::retrieve(
$event_json->id,
array("stripe_account" => $user_id)
);
My requirement is, from my application I want my user to transfer the amount to another user of my application. Assume that both user have stripe account. I have gone through stripe docs, and I understood that in order to do transfer from one user account to another I need to use stripe connect. I could able to do authentication and I'm getting access token successfully for the sender. How can I make a transfer to a recipient ? I have only recipient's email id with me. Should I need to create a recipient through code and do the transfer using that recipient id returns from stripe ?
Im using php. Please help me.
Stripe Connect doesn't work like that. Instead, Connect allows an application to make card charges on behalf of a user and take a portion of the amount. The rest is automatically and immediately put into the user's Stripe account, where it's subject to the normal bank account transfer rules (2-7 day rolling transfers or API-driven manual transfers).
Another way to do this is using Stripe Recipients and Transfers. For example, your application charges a customer $10. You create a Recipient for your user using their bank account information (account number and routing number). Then, you can create a Transfer from your Stripe account to their bank account. Note that this only works for US bank accounts as of today.
If you really want to do user to user transfers, unfortunately Stripe isn't the platform for you. You could use PayPal or you could possibly use Balanced Payments, although again you can only transfer money to and from US bank accounts.
I think that the Dwolla API sends the wrong transaction ID in notifications. In a normal dwolla money transaction, two transaction IDs are created (this is weird to me, but that's how dwolla does it). Because these two are created at the same time, they are always (in my experience) consecutive numbers.
So e.g. if account X sends money to account Y, Y will see transaction id M, and X will see transaction id M+1.
But Dwolla's notification webhook will send Y details of the transaction with id M+1. While ID M+1 is still unique to this transaction, ID M+1 cannot be used by Y via the API - because M+1 is supposed to only be used by X.
Here is a specific example:
Via my webapp, I send money from my personal dwolla account to my organization's via the off-site gateway api.
My webapp is sent the transaction details in both callback and notification form. The transaction id generated by step 1 is 1431566. This is the transaction id sent to both callback and notification. My web app stores this Id for future use.
Via my webapp, I decide to refund my personal dwolla account from my organization's so:
My webapp tries to query dwolla about transaction 1431566, to get the SourceId, but this fails - dwolla reports "Transaction not found for account". My automatic refund cannot continue without an ugly kludge like subtracting one from the Id and trying again.
The manual workaround is to login to my organization's dwolla account via the web interface. Here I can look for the transaction based on datetime and I can see that the transaction ID is actually 1431565 (correctly reported in the web interface). If I go into my organization's database and replace 1431566 with 1431565, I can repeat step 4 and it works this time. After that I can initiate a send() and the refund goes through.
I reported the same problem here before dwolla moved support to stackoverflow: https://getsatisfaction.com/dwolla/topics/callback_and_webhook_notification_sent_wrong_transaction_id_off_by_one
I figure it will be fixed faster if other people have the same problem. Or maybe I'm missing something obvious and someone will point it out.
Thanks to Michael's help, we were able to get around this issue by using the receiver's OAuth token when getting the transaction details instead of the sender's OAuth token.
For example, say I send some money using the API and transactions 1202 for the money sender and 1201 for the money receiver get created. If you make the API call to get details for transaction 1202 but use the receiver's OAuth token, it will give you details for transaction 1201, including fee information.
I'm not sure if the situation is exactly the same since we are acting as the facilitator between two transactions, so no guarantees that this will work in your situation. But it's worth a try.
So, your application's key & secret can access the transaction ID posted to you by passing the transactionById() method your application's client_id and client_secret, as opposed to the oauth_token. Meaning, when you poll for the transaction, instead of querying this URL:
https://www.dwolla.com/oauth/rest/transactions/{transaction_id}?oauth_token=x
Query this url, instead:
https://www.dwolla.com/oauth/rest/transactions/{transaction_id}?client_id=x&client_secret=y
Makes sense?