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.
Related
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.
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
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 am using Stripe for online payments but also users can pay offline (cash or check). I want to centralize all my invoices/charges in one place (Stripe).
I am not sure if I can add offline payments (cash or check) to stripe or not. I guess I can if I created customers, invoices, charges with livemode=false for my live keys.
Is this feasible and will Stripe accept having some (customers, invoices and charges) with livemode=false and others with livemode=true?
If yes, should I fill fake credit card info or should I set it as nil?
Stripe does not allow you to create a Subscription on a Customer if you don't have a credit card setup. More accurately, it does not allow you to create a subscription if a customer does not have a way to pay for the next invoice. So for offline payments, you could update the 'account_balance' on the customer to have a negative value equal to the amount the customer wired (credits). Stripe will then allow you to create a subscription for the customer because it knows that the customer has enough account balance to pay for the next invoice. This post has more details.
We don't currently support offline payments, so you'll want to look at a separate accounting system for those payments.
That said, it's totally understandable that you'd want to keep this data in one place. You might be interested in using our webhooks system to offer live updates to your accounting system without directly touching the code that creates the charge in Stripe.
I can find a good payment solution for my site and recurring payments. I've been looking around but can't find any great way of doing it.
On our site our customers are spending virtual credits. The charge their account with new credits when their credits are out. We want to provide them with an automatic refill functionality but we do not want to deal with all the PCI-DSS problems that comes with it.
Basically I'm looking for the following functionality:
The payment provider should expose (secure hosted pages) where the customer provides all credit card details.
My site loads the hosted pages with some customerID (to be able to map tokenID with customerID in the last step).
When the customer has registered his credit card details the payment provider sends a notification to my site that credit card details has been tokenized with a tokenID for customerID.
In the future I charge my customer with an API call:
API::charge(currency,amount, tokenID);
Is there any payment providers out there that can do this?
You can't use a normal recurring billing system if the amounts change from cycle to cycle. The best you can do is use a service like Authorize.Net's Customer Information Manager (CIM) to store the credit card and billing information for you and then you create your own scheduling engine that charges against the payment method you have stored for them using CIM. CIM also allows you to make off-cycle payments at any time as well.