I'm adding a payout to connected partner accounts through stripe, while I can easily get if they have a payment intent and check if it has succeeded I can't determine if that succeeded payment intent is in the stripe account for payout yet.
I tried using stripe.balance.retrieve(); but this doesn't tell me which payment intents have succeeded and transferred into the stripe account balance for payout.
This is possible by looking at Balance Transaction status of a Charge. If the status is available, it means the fund is ready in account balance for payout.
To retrieve the Balance Transaction status of a Charge, you can expand the latest_charge.balance_transaction field using Payment Intent Retrieval API. For example,
curl https://api.stripe.com/v1/payment_intents/pi_xxx \
-u sk_test_xxx: \
-d "expand[]"="latest_charge.balance_transaction"
Basically, you can't.
After all, you can with some alternatives ways.
If you put in payment intents metadata the date where payments will be available (the date depend of Stripe configuration, 7 or 3 days), you'll be able to know which payments is in your Stripe balance.
Thanks to metadata, you can edit them manually or with an API call when creating payment intent.
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.
I have a payment system with stripe payment intents, where I store the CC data in a stripe customer, and then complete the payment with StripeService.charge_customer.
One customer must have had troubles with their CC, so the payment remained pending for a while before it was completed.
In the meanwhile they closed the page an went on with their business, so my application hadn't been updated and the payment doesn't figure.
I have on DB the stripe customer id, and nothing else about this payment, is there a way to verify that the payment was completed successfully?
thanks,
You could check the Dashboard page for that customer, which will contain a list of all associated payments.
Alternatively you can use the API. List all Payment Intents and pass the customer parameter, which will return only Payment Intents associated with that Customer object.
I'm trying to work out the correct method of attributing payments on invoices that are automatically created after a user purchases something on site, payment handled by Stripe (or other payment gateway). Here is the current flow from user action to Xero interaction (all working fine):
User purchases membership on site
Payment is processed by Stripe on-site
If payment is successful, an Invoice is generated in Xero (and a contact if it doesn't exist)
Payment is added to the invoice immediately after it is generated, and it's status is set to Paid.
Paid invoice is emailed to new member from Xero
Stripe deposits money in nominated business account each day
I have two questions about this workflow
What is the normal practise for dealing with PaymentAccount when applying a payment? Should we create a new payment account just for Stripe? A new "Bank" account for Stripe? The context of this question is selecting the correct PaymentAccount ID for the payment when creating the invoice.
Will reconciliation still be possible for these paid invoices when Stripe sends payments (assuming they send itemised payments)? Even if the money is deposited in a different (Real) account integrated in Xero?
Thanks
Your questions about stripe are more appropriate in Xero forums, since they are bookkeeping questions not API qestions.
Stripe can provide a bank feed to Xero, and you should set this up.
This means you have a Stripe bank account, which is the therefore the payment account. Payment reconcilations are easy (but can't be done via API).
The actual deposit of real money into a real bank account will be a consolidated amount typically called a 'settlement', typically one day of transactions, less fees, refunds and possible timing issues etc. The Stripe bank feed will have an entry for this. It is reconciled by a Xero user as a bank transfer between the Stripe bank and the real bank, and is nothing to do with the payment on the invoice.
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.
In our system we use Automated Recurring Billing for our members. We check our users subscription status from Recurring Billing API. We check failed payments from Transaction Reporting API and it appears that some of the subscriptions status code return “active” from API even not charged. Let me give a scenario about it :
A user has an ARB monthly subscription which payment cycle is 14th of every month. User has been successfully charged for 3 months. But on 4th payment, we saw that the payment failed and response code from API is “this transaction has been declined”. We think that credit card expiration info may be failed and user may update it. So we put the user in a grace period(two days) and let user update credit card information. If user updates credit card information in two days we call API to update subscription with new credit card info. Let’s say this update subscription request is done on 16th of the current month. Can we get the payment which has passed on 14th ? Or has user been charged on 16th which update subscription request is sent and is ARB payment cycle changed from now on ? Or user will be charged on the next month and we can not get failed payment ?
I could not find any details about failed transactions payment flow when credit card info is updated. Thanks in advance.
A failed subscription payment won't be retried after you update the customer profile. However, you can use the updated custer profile to make your own one-time payment.