Is it possible with Stripe to perform a test transaction to ensure that an account is funded?
I would like to :
take the Credit Card ID at the moment of the booking (but no payment at that moment)
make the customer pay AFTER the service has been done
What you likely want is to place a hold on the card for the given amount, and then capture the funds later after the service has completed. When placing a hold the given amount is authorized and guaranteed by the cardholder's bank. You'll often see these types of transactions show up on your online bank statement when renting a car or when checking-in to a hotel room. When processing your payment with Stripe you would set the capture_method on the PaymentIntent to manual which tells Stripe to only authorize the given amount. Then, once the service is rendered you would capture the funds. The following guide covers the approach in detail:
https://stripe.com/docs/payments/capture-later
Related
Pretty new to Stripe, we're building an online marketplace. Each user can buy assets from any other user. We also take fees for each payment.
We go with connected accounts. Seller goes through the onboarding flow (create connected account, create account link etc), while buyer is registered as a customer of our platform on Stripe.
Now, whenever buyer makes a payment we create a payment intent to pay to us (amount + 20% fee via):
stripe.paymentIntents.create(params)
Then we create new payout to seller (amount) using source transaction from payment intent above:
await stripe.transfers.create({
amount: payment.amount * 100,
currency: payment.currency,
destination: seller.stripeAccountId,
source_transaction: sourceTransaction,
});
Is this the preferred and best way of handling this? In terms of time, we need first to wait for payment to settle to our bank account to be able to payout seller?
Is there any better way of doing this instead of manual payouts?
Is there a way to make direct transfer to connected account when user does payment?
I tried with payment intent, specifying connected account id in request, but API is complaining that customer id is on our platform but account id is specified, so it's not possible obviously.
Also, manual payouts would come handy to simulate payment escrow/deposit. When user create a request for some asset, we would immediately transfer certain amount to our account, like reserving that amount. And if the seller accepts the offer, we would do a payout. If seller rejects the offer, we would do payout to the buyer, giving him back his money.
Does this make sense?
Thanks in advance
You don't need Payout (yet) in your use case. You are doing Separate Charges and Transfers, and fund simply moves from your Account's balance to Connected Account's balance. It hasn't been out of your Connected Account's balance to your Connected Account's bank account yet, which is called "Payout".
In another word, Payout is separated process than Charges and Transfers. Charges and Transfers can happen immediately, and Payouts normally happen later on a daily basis or manually.
Find more explanation on Connect Balance.
There is also Destination Charge which is simpler than Separate Charges and Transfers. I recommend Destination Charge unless you have specific reason to use Separate Charges and Transfers, ie. you need to transfer to multiple Connected Accounts on one payment.
We have our own payment processing system. This takes a customer token from Stripe's response after initially checking out, and uses it each month to charge the customers card.
We want to do similar for mobile wallets, like Apple Pay.
However, Stripe docs indicate that it only returns a token which is 'single use', so the customer would have to authenticate the payment each month:
We aren't able to integrate with Stripe's 'subscriptions' service, as we'd have to migrate across entirely to Stripe - which we can't do.
So as a result, is it possible to get a reusable token - or does the 'subscription' it's referring to mean that we can get a reusable token in the same way as a standard card payment?
And by reusable token - I mean, the customer doesn't need to authenticate the payment each month.
Hope that makes sense!
When you accept an Apple Pay payment, you can still save the underlying card for future payments. This will then work whether you use Billing (their recurring payments product) or just create one-time payments yourself.
The call out from Stripe in their docs is more around the rules coming from Apple. If your customer is checking out in your application or website, you are expected to show them the Apple Pay UI to confirm the payment again instead of using a previously saved card. On the other hand, if you are doing recurring payments, you can use the previously saved card for future payments.
The integration itself is fairly straightforward. You would create a PaymentIntent server-side and collect the card details client-side whether via Apple Pay or not. Since you want to save card details for future payments you would also pass setup_future_usage: 'off_session' on the PaymentIntent creation. After a successful payment, a PaymentMethod of type card would be attached to the customer with the id pm_123 and you could use this in future recurring payments.
This flow is covered in Stripe docs here and also applies to Apple Pay and this section covers how to make the future payments.
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.
I want to handle the following use cases with Stripe:
Charge a customer on a regular schedule where the interval between charges is not a single number, e.g. charge on Tuesdays and Thursdays.
Charge the same customer at one off instances, e.g. they are regularly charged on Tuesdays and Thursdays but for this particular week, Saturday also.
Can I fulfill these use cases with Stripe without needing to generate a new token each time (i.e. take the payer's card details each time)?
You don't need a new card token each time. Card tokens are created client-side, for example via Elements. They allow you to collect card details securely client-side and then simply send the card token id (tok_1234) to your server to charge the card.
When using a token, you have two options. First, you can charge the card once using the Create Charge API. Otherwise, if you want the ability to charge the card more than once, you would save the card on a customer. This is covered in details in the documentation.
Once a card is saved on a customer, you can use the Create Charge API to charge that card. You would pass the customer id (cus_123) in the customer parameter and if you want a specific card you would also pass the card id (card_abc) in the source parameter.
You can try to charge the card as needed on days where you expect a payment. It's up to the cardholder's bank to decide if they want to let the charge go through or not.
I would like to implement a guarantee payment system on a website I'm working on. By that I mean that the user would insert his credit card information but no money would be drawn from it at the moment he does so. The money could only be drawn if the client does not show up at the hotel to actually pay for it. In that case the owner should be able to get some amount back. I was looking at Braintree payments but haven't found anything in their doc mentioning a system like this. How should I go about it?
You want to do an Auth Only transaction. Auth Only transactions are very similar to Authorize & Capture transactions except the transaction is not captured. The merchant is issued a six digit authorization number indicating that the funds are available and the transaction is approved. However, the merchant will not receive those funds until they capture the transaction.
Authorizations are only valid for up to 30 days from when they are issued and for up to the amount they were authorized for. For example, if an authorization was obtained for $100, the merchant may use this authorization for any transaction up to $100 for that customer. However, they cannot go over $100 with that authorization number.
An Important thing to note is that the funds from authorizations are frozen on a customer's credit card and cannot be access by that customer. From the customer's point of view, that money is essential spent. Authorizations should not be used without a customer's consent and with care.
Authorizations are captured when a Force transaction is processed.