The use case is this; we have automated fraud detection in our system, and if we detect something that could cause money to be paid from Stripe to a bad actor, we want to pause the periodic Stripe payout from Stripe to the customer's bank account (eg: Stripe's "external account" for that customer).
There is a way to do this on the UI: https://stripe.com/docs/connect/pausing-payments-or-payouts-on-connected-accounts; dropdown on the right. I'm looking for a way to do this with an API call.
Once the fraud has been investigated and deemed OK, our operations people will use the Stripe console above to manually un-pause/continue the payouts on the normal schedule.
I'm not an expert with the Stripe API but didn't see anything in the documentation that seemed the right thing. Or even close, really.
This depends on how you are currently managing Payouts, Scheduling or Manual.
If you are using the Scheduled approach your application can trigger a change to the Connected Account when it detects something that could be fraud, setting the payout interval to manual. This will pause any payouts unless you directly trigger them via the Dashboard or API.
You could also try modifying delay_days to give yourself a little more time to run your fraud checks and shorten them to the minimum again if/when everything checks out.
Of course, if you are using just Manual payouts then you would just not trigger the payout.
Related
I am using UPS APIs to figure out ratings and create shipments and now I'd like to track shipments in real time. I know there are a lot of services that provide tracking aggregation for different couriers, including UPS, via webhooks, but I am looking for a "native" UPS API for the real time tracking that would not require me to keep poling for updates.
I went over the UPS API docs and could not find anything. Is there such an API that offers webhook type notifications or something similar in UPS? If not, how do those services like EasyPost, ParcelMonitor, TrackingMore and others can offer such functionality?
I'd like to track shipments in real time
"Real-time tracking" is a misnomer in the shipping technology industry. EasyPost does provide webhook events to notify you of updates, but those updates will never come in "real-time" and no tracking service provider should ever make such a claim. There will always be some kind of delay between when the carrier updates their system and when the updates are able to flow through providers like EasyPost. The delay may be short, but any delay at all means that "real-time" goes out the window.
Being an EasyPost employee myself, I have to disclose my bias and say that I believe EasyPost can help you get updates as promptly as possible for UPS shipments.
The nice thing about setting up webhooks with EasyPost is that you don't have establish your own logic to repeated poll for new tracking updates. This can save you network bandwidth and reduce the complexity of your code and it can help you get updates sooner than if you were trying to poll updates on your own intermittent schedule.
Because I don't really have access to my online bank account for a while. I wanted to see how much money I have made and how much I gave out and want to create an app to keep track of that.
My problem is my income goes direct into my bank account and my payments are trough PayPal. So my question is how can I get my past PayPal transactions?
I don't really find anything about that and the PayPal Documentation just confuses me
Thanks for the Help
The Transaction Search API is quite limited in its capabilities and use cases.
Instead, log in to https://www.paypal.com/signin and click on the Reports tab. Use the Activity Download, and choose csv format if desired
[React/NodeJS] I'm having a huge struggle in finding the appropriate documentation on this topic -- I am looking to implement PayPal on my website, with the constraint being that the customer is charged after our offline service is completed (has variable costs, but there is something of a solution in mind such that if I can 'authorize' an amount equal to our maximum cost that we will be a-okay). My initial research indicated to me that PayPal Orders fulfill this desire, to at least an effective extent, ie. the order is placed and funds are not placed on hold until we authorize the charge, ideally after the offline service is completed (source: https://developer.paypal.com/docs/integration/direct/payments/orders/#order-response). Upon further inspection, I have discovered that the integration path using PayPal smart buttons is being heavily advocated in implementation docs and appear to be compatible with the orders API (source: https://developer.paypal.com/docs/checkout/).
I began working to implement the software, following the smart buttons implementation linked just prior, and followed the instruction to use server side api calls to process the payment (source: https://developer.paypal.com/docs/checkout/integrate/ and https://developer.paypal.com/docs/checkout/reference/server-integration/set-up-transaction/). Continuing forward, I pursued order creation explicitly using the orders API (mistake perhaps?) and used the docs for the v2 orders api and the docs for the nodeJs sdk package referenced in the paypal docs (paypal/checkout-server-sdk using the github docs). I set up the integration and the sandbox accounts showed that charges were being placed however, and this was contradictory to my desire to not place charges on hold until an authorization is completed. The status returned on the backend is kept at "created", so I was initially optimistic, but the charge placement was unfortunate.
I am struggling to find the next step. As the checkout-server-sdk is utilizing both payments/v2 and orders/v2 (source: https://www.npmjs.com/package/#paypal/checkout-server-sdk), I am lead to believe I can utilize those API endpoints as well, but can't find explicit functions that call the payments api in question in the checkout-server-sdk, which I believe I would need to change order intent in order to create an order (source: https://developer.paypal.com/docs/integration/direct/payments/orders/), but also noticed these docs (linked as active directly from the docs page for paypal I believe -- https://developer.paypal.com/docs/ ) post to payments/v1 (source: https://developer.paypal.com/docs/integration/direct/payments/orders/) which has been deprecated. Long story short, I am now lost and would thoroughly appreciate some guidance on where I walked astray, what docs to refer to, if this implementation is still supported, and potentially what the next step is. If I used incorrect verbiage or have some noticeable jump in logic that was to my detriment, I would love to know as I am fairly new to developer work as a whole. Thank you in advance!
Your use-case of not placing a temporary hold up front requires intent:order, and only the v1/orders API has this available. The v2/* APIs do not.
An intent:authorize hold typically clears from a card after about ~3 days (even though it is capturable up til day 29), so I would recommend using the v2 APIs if that's workable. But if it's important to not do that, then v1/orders can be used. The API is not going to disappear, people are using it. Even-yet-older Classic APIs with similar PAYMENTACTION=ORDER functionality are still in heavy use, after all.
My problem:
Currently in my project it's required to keep a payment in an uncaptured state for more than 7 days which is the maximum for stripe.
What I came up with atm:
I see that it can be done by remembering customer's card (using stripe's api for this of course), creating an uncaptured payment, refunding it when the 7-day period comes to an end and creating it again until we choose to finally capture it.
I guess this 'hack' will be used only once per a payment as usually we have to hold the payment for about 10 days.
Questions:
Are there any pitfalls besides that a customer will see a second payment?
Any other ways to handle this?
Thanks in advance :)
So we ended up sticking to this method described in the question, but #korben's point is true, it's still hard to handle because even if a bank can release the funds fast, we still don't know when exactly does it happen as stripe can't inform us when the customer actually got his money back whether it's two minutes or two days.
It still works for us, because the payment is not that big and happens in person, so customers can choose whether they want to give a deposit in cash or use this method which seems more comfortable.
For context (because I was recently solving this problem and came across this thread), a number of websites recommend if you have a payment that wasn't captured within seven days, then cancel the order and create a new one. For example, Shopify recommends this and the authorization expiry date is displayed on the Orders page.
However, for all of the reasons #korben mentioned, it's best practise to avoid holding authorizations for over 7 days. Additional fees are also charged when collecting charges after the standard authorization period (depending on the issuing bank of a credit card).
The create refund action is currently in pipeline on the Stripe integration for Zapier and isn't supported as of today. Support at Zapier suggested that I should post a question here to see if someone could point me in the right direction for creating this (if at all possible). Maybe the "Code by Zapier" or "Webhooks by Zapier" integration is a workaround that can be used? https://stripe.com/docs/refunds
David here, from the Zapier Platform team. That's definitely something you can do, though it'll take some programming work on your part.
You'll need a Stripe API key (which can be found in your dashboard). You'll want to use a Code by Zapier step in your preferred language and make the request described here: https://stripe.com/docs/api/curl#create_refund. You'll need to get access to a charge id, which could be pulled from a New Charge trigger or Find Charge action.
Hopefully that points you in the right direction!