This is our first time using Stripe and we have noticed that Stripe makes a lot of requests to the m.stripe.com/4 url. This only happens when the URL changes, which it does a lot for our single page application.
This site is build with React using Stripe-Elements from here: https://stripe.com/docs/recipes/elements-react
Is this normal? Is there a way to op out of this kind of analytics gathering? I feel like a framework shouldn't be that aggressive on watching the user move around the site.
Stripe collects this data for fraud protection, but I agree with you that it should give site owners more control over what data they share.
As of #stripe/stripe-js v1.5.0, you can disable this behavior by setting {advancedFraudSignals: false}:
import {loadStripe} from '#stripe/stripe-js/pure';
loadStripe.setLoadParameters({advancedFraudSignals: false})
const stripe = await loadStripe('pk_test_TYooMQauvdEDq54NiTphI7jx');
Note that disabling this feature increases your risk of receiving fraudulent transactions.
I wrote a more detailed blog post about this if you're interested in a more detailed discussion: https://mtlynch.io/stripe-recording-its-customers/
Those are requests containing behavioral events that Stripe tracks. Main reason is to provide data for Stripe Radar and prevent fraudulent requests before they can happen. You can't really turn them off as they are primarily for fraud detection (and in your best interest).
Related
Background
I am integrating stripe API into my site to take one off payments. My site will be API first on server side with a separate web and mobile front end. I am working on the API server side code. I will eventually use stripe payment pages to take credit card payments. I am trying to automate the testing of my APIs and am bamboozled by the documentation (which are thorough) as I just can't see what steps to take next.
My server side initiates a call with stripe using stripe sdk to create a stripe Session object - this contains a URL to redirect to checkout.stripe.com/pay/..., a success URL when payment is successful and a cancel URL (these I set to handle the callback).
Problem
I can automate in Postman all my API calls from Browse Products, Select Product, Place Order but the next step I am stuck. After Placing Order I get back the stripe session but how can I mimick making the payment with stripe for the session and then call my Success URL ?
When the site is complete I will redirect the UI to stripe to take payments but I am testing and completing the back end flow first.
I have copied and pasted the session URL which is returned by the stripe Session object to bring up the page in a browser and used Dev tools on Chrome to inspect Network to see which APIs are being called by stripe in an attempt to reproduce and I can see a POST to stripe.com/api/payment_methods and I can see the posted values but I can't reproduce this in Postman. Also, the documentation (https://stripe.com/docs/api/payment_methods/create) says
"Instead of creating a PaymentMethod directly, we recommend using the
PaymentsIntents API to accept a payment immediately"
Question
Which stripe APIs do I need to call to automate the flow from a stripe Session object to make a payment and then check that it was successful? Payment Methods? Make a Charge? Payments Intents? ...and how. Happy to be pointed to the documentation if you can help me understand the flow.
TIA
Checkout is a Stripe product that looks like a "box" and you can't know (and shouldn't need to know) what happens inside. It is created for the purpose that merchants won't have to think about what's being done under the hood.
Speaking from an automation perspective, you can try to reproduce the whole process but there's no guarantee it won't change in the future, and it could leave you with more problems later.
For options to reproduce:
The closest way is simulating browser filling and submission, using automated browser tools (ie Selenium). But it's not as straightforward as PostMan. Generally you would want to simulate every browser action that a human could do.
Or you can try to accomplish the same with the logs and events you receive on Stripe's Dashboard, when you test a Checkout Session by yourself. From now there are 3 requests.
And your goal is to receive the same 5 events in Webhook:
TBH I recommend to reconsider the need of this test, to see if it worth your efforts.
In the past, Instagram autoliker, autofollower, like exchanger bots worked with the Instagram API. Thankfully, to keep Instagram - bot safe, they deprecated their API functionallity, so developers can no longer use Commenting, Liking endpoints.
But nowdays, I'm again meet new and new spam comments under a picture in the feed.
I did some research about the new autolikers.
How did the developers, like SocialCaptain bypass the API deprecation?
Are they simulating the user browsing instagram.com?
Actually you can just monitor the requests being sent from instagram.com. Open the developer tools and navigate to the Network tab.
Now you can reverse engineer their API by looking the requests they send on particular actions. The only thing left is to supply the proper body, headers, cookies, etc and perform the requests on your own outside of instagram.com.
Hope it helps !
I would like to know if this is possible to add new payment method for Bigcommerce. I tried to contact their support without any luck. If anyone is familiar with bigcommerce and know if this is possible, i would appreciate any advice.
I already read their API docs and didn't found anything useful - only method to obtain list of available payment methods.
I already tried to signup for their partner. Without any luck.
We've done this before for a couple stores to allow clients to process payments through their own processor. The way we achieved this, is essentially through the following high-level steps:
Allow payments by Check (or similar offline method). We are going to replace this with the custom processor.
You'll notice that if you attempt to checkout via Check, that BigCommerce automatically creates the order for you, but sets the order status to Awaiting Payment. Upon submission the user is automatically sent to a 'Thank You' Order Confirmation page that contains both the Order ID and some payment instructions (such as where to send the check to).
Here's the trick -- Modify this 'Order Thank You' page to prompt the user for her or his credit card information. A simple HTML form will suffice here, performing the actual request via JavaScript.
Once you have the user's credit card data, you can then POST it to your own external server, where you would connect to and send data to whichever processor you are using. Additionally, you should make sure to send the Order ID to this program, so that you can connect to the BigCommerce API to load billing information, and then subsequently adjust the order status to either approved or declined depending on the response from your processor. Finally, you should send back some sort of response to the client to inform of the result of the charge attempt.
That's pretty much it in a nutshell. The way you integrate with the payment processor (step 4) is unique to whichever processor you are using. I hope this makes sense.
Although opinion based, I'm a huge fan of serverless technologies, and would suggest looking into AWS Lambda + AWS API Gateway. The benefit here is that you don't need to worry about creating an infrastructure or the associated concerns of security and scale. Rather, AWS Lambda allows you to simply upload your software, and allows it to be executed via an HTTP request to some defined endpoint set through the API Gateway. Lambda will scale automatically for you, and you don't need to worry about system level security concerns - only security at the application level. It's truly a set and forget setup, and a bleeding edge technology. Not to mention dirt cheap!
Implementing a new payment method is unsupported and requires hacky workarounds since we implement payment gateways via the core app. You can do this on blueprint by using an offline payment method and then using the API to update payment statuses, etc. I'd recommend using ActiveMerchant if you do wish to go down this path.
The native application doesn't show all the activity, only the most recent.
Therefore I lose 70-90% of my notifications overnight. There must be a way to get all that historical data.
I told you can't, but, thinking.. you can. :)
The API don't provide that facility.. You can check all endpoints here: http://instagram.com/developer/endpoints/
But you can iterate over all your medias an get all comments and likes. If you store it locally, after, will be possible to request API again and check your new unseen interactions.
It will work for likes and comments.
I created an iOS app that using Instagram API and have a critical issue posting likes to Instagram.
Using endpoint – POST /media/media-id/likes, with user-specific access token. I request scope – likes from users.
Instagram API works fine for all requests except saving likes. We can only save/post a couple hundred likes to Instagram, and then response is "We've taken extra measures to protect the Instagram API from abnormal activity. Since you have recently created your API application, please contact apidevelopers#instagram.com to receive whitelisting for a higher rate limit."
There is other developers with same issue with no support or any feedback waiting for months.
Please, let me know if there is limits and how it works, or how to become whitelisted
I don’t want to create many Instagram API clients and assign users among them. It seems like bad acting for me, if there is official API with strict limits I want to work with it.
Instagram has new API limits: 100 likes/hr 60 follows/unfollows/hr per access token. That is only if you authenticate serverside and sign your headers. Check out the new authentication: http://instagram.com/developer/authentication/
I'm using it for my new site that automates likes/follows/unfollows, haven't had any problems works great. Check it out: http://instapromobiz.com
Instagram takes increased measures to limit your API requests based on IP address. This is not common knowledge, it's just something I've come to know from working with the API extensively.
They've built an API that is FAR from perfect, but have been upgrading it to be "smart". Smart enough to know that a newer client, pinging the API many times just for one user, may very well be a script kiddie trying to bot the system. For this reason, they do not give you a rate limit error, they politely say "we have taken extra measures to protect our API from being spammed by bots".
The good news is, other users should still be able to access your liking mechanism. Just not you, from that IP.