I have a tested app that will hopefully go live in the short term.
However, it has 3 in app purchases.
If the situation arises where I need to do a further test of purchasing the in-app-purchases, is there any way I can cancel my own personal in-app-purchases up to that point so I will be testing from scratch?
Note: I am using the new Windows.Services.Store.StoreContext method, and not the old one.
First, there's no such API that can cancel your in-app-purchase currently. But you can still do your further test.
If the situation arises where I need to do a further test of
purchasing the in-app-purchases, is there any way I can cancel my own
personal in-app-purchases up to that point so I will be testing from
scratch?
According to your description, it seems your IAP type is durable. If so, you can specify the duration for the product as 1 day so that you can repurchase it after it expires.
If your IAP is developer-managed consumable type, you need to report the previous IAP as fulfilled after the user consumes all the items. Then they purchase it again.
If your IAP is Store-managed consumable type, you need to report any items consumed by user as fulfilled to the Store and the Store updates user's balance. After users consume all the items, the user can purchase that IAP again.
For more details, you may refer to In-app purchases and trials.
Related
I am implementing the Stripe payment platform using JavaScript and the PHP SDK.
I don't have any issues with the implementation itself, but I am not sure whether I have to reuse an existing PaymentIntent or it's perfectly fine to have a bunch of them created and incomplete.
I searched for this in Stripe's documentation, but I can't seem to find anything related to this.
For example, in my test account I have this:
It's all for the same transaction, because I was changing some visuals and refreshing the browser.
I am aware that each PaymentIntent has an ID, but is it recommended to add it as a query parameter and retrieve it on refreshing, or is it better to always generate a new Payment Intent.
My main reasoning is to avoid having a huge collection of incomplete payment intents.
The default integration path for Stripe today is to create a PaymentIntent first so that you get a client_secret you can use client-side to render their UI via PaymentElement. This means that if your customers decide not to pay after all, you end up with an incomplete PaymentIntent which is expected.
This is not really a problem, other than appearing in the Payments list which can be confusing. You could also write a background job daily that would cancel any PaymentIntent via you know won't be completed because the customer left and you didn't have any data to contact them to upsell them for example but this isn't really needed.
Stripe also has a beta (docs) right now (Feb 2023) that changes the default integration path. This simplifies the experience because you can render the PaymentElement client-side with specific options such as amount and currency. You'd then only create the PaymentIntent at the end of the flow
when the customer is attempting to pay. That flow limits the number of incomplete PaymentIntents since you only create them when the customer really pays. You'd still get some, for example after a decline by the customer's bank though.
I am new to transferwise and want to ask if the thing i want to do is achiviable via the wise-api
The platform/business needs to automate one action among others:
Business need to ask the User to pay via Wise whenever they feel like ready.
Business give the balance account details (Wise balance account) (i think it is the borderless account, right? or is one of the overseas balance accounts [usd, eur, gbp...] )
User pay to business
Via webhook (i think so) we manage the user info and linked the stuff to the DB
Would be nice if i can use the "Request money" flow-endpoint which give you a payment-link with 14 days of exp. But i think you can't use that in the api :(
Are someone who made something like this before using wise?
I'm so new to wise and it is my first time implementing a thing like this from scratch (i'm the only backend dev haha)
I tried to folllow the docs, and i see the endpoints to do this in the Postman Collection, but i dont know if can solve the needs of the business.
If this the only way?
I cant use the "Request money" flow with the api?
Big thanks for reading!
I am building an app to sell single item product (i.e, each kind of products listed on my platform only has a single item).
(this part has been done, and won't change) I built an in-house backend having the Rest API POST -D {"buyer_email": "abc#example.com"} url/items/{itemID}, let's call it transaction_call, which will make sure once a customer succeed the POST operation, his contact info is recorded into my backend as the successful buyer; and all other customers will fail to buy that item (at API level, transaction_call return 4xx error) because my platform can only sell one item for that product;
(this is the step that my current question is about) I am trying to use Stripe as my payment system on this platform.
I really want to integrate with Stripe as simple as possible (as I understand Stripe Checkout is the most simple / out-of-box way to implement payment). However, I am not sure if Stripe Checkout can achieve the above functionality correctly. Since the problem is a two-step problem, here is the potential issue I may run into:
Let's say, two customers A, B, get to my platform at 10:00am, both of them start purchasing process for a product, Item_a
If my system interact / call the Stripe Checkout first as the first step then call the transaction_call, here could be the problem:
A's Stripe call hits the Stripe server at 10:00:01am, and A's buying call hits my backend at 10:00:02am;
B's Stripe call hits the Stripe server at 10:00:01am, and A's buying call hits my backend at 10:00:03am;
in this way, we have already charged B but he really did not get the item
If my system calls the transaction_call first, and only if transaction call succeeds then it interacts / calls the Stripe Checkout, then
A's transaction_call succeed at 10:00:01am, but he for some reason decided not to pay (not click confirm button on the Stripe Checkout UI)
In this way, my system fails to sell the item to other buyers.
My question is whether the above reasoning process is correct, and whether I could somehow use Stripe Checkout to achieve what I am doing.
Maybe I have implement the payment functionality using Stripe Intent API to build a workflow-based payment, which I assume will be much more complex, if the Stripe Checkout way (simple wayO is really not possible.
From what I understand you have a potential race problem, where the item you're selling is very limited in quantity and you want to make sure that you can correctly notify users if it's out of stock or already spoken for.
For your first scenario, the simple solution is only invoke Stripe's API on your backend when you've received the transaction_call. For instance, you'd only create the Checkout Session once your system has identified that the item is still available. You'd then "lock" the item so that when B attempts to purchase you can immediately return an error instead of creating a payment via Stripe's API. The logic on who to charge (basically who initiated the checkout process first) in the case of a tie would then be for you to implement in your transaction_call rather than on Stripe's side.
The second scenario is a little tricker, as Checkout Sessions can't be cancelled once you create them. They automatically cancel themselves after 24 hours if no payment is made, but I doubt that you'd want B to have to wait that long if A abandons the payment flow.
Instead I think you should look at implementing a PaymentIntents integration, where you can more finely control the flow.
Your flow for scenario 2 could be:
A begins the checkout process, create a PaymentIntent on the backend, "lock" the item and start a timer
The timer (which you'd ideally show to your user) times out after N minutes if A doesn't pay
Cancel the PaymentIntent on your backend and remove the lock
B can now attempt to pay for the item, upon where you restart the process
Instagram API permission is strict now and I want to know whether the tool my company will make can get the permission from Instagram or not, because it may not suit with the 3 valid use case.
We are an offshore company which develops application.
One clients ( PR or Advertisement company) asked us to make an app which finds influencers(the user who has many followers) on Instagram so that the clients can ask the influencer to advertise their products.
We want to make a influencer searching tool. Lets, say if you search with #Chocolate, the list of users who have posted photos with #Chocolate will show up, and we want to sort out the list according to the number of followers.
Referring to the valid use case for Instagram, which case may be suitable for the app we want to make?
Also, by one-off project, what does it mean? We are an offshore company and get orders from a client which want us to make a tool for them. If we just make it, and will not sell or use the application again, would it be "one-off" project?
In order to avoid one-off project, do we need to keep selling or offering the app ?
There is no direct API call to make this. You have to make a series of API calls to get all the posts for hashtag, this will have user_id and name. Then for each user you have to make another API call to get followers count. And then you have sort the results and make query for >3000
For example #chocolate has 1 million posts, so to get all 1 million posts you have make about 50000 API calls (u get 20 post per API call), and then you have to make 1 million user_info API calls to get follower counts, so 1050000 API calls total and you have 5000/hr API calls limit. So to complete this operation it will take you 9 days.
This will be a one off project if u do for a client use, you have to make a platform or service for this feature and have your client (and others) login and use the service.
In any case, the project is unrealistic to implement due to the limitation of APIs
Everything that I read about AdSense says that I need a website (blog, domain, etc.) which I do plan to get. I'm just not sure about the name of the domain that I want.
However, I want to be moving on, because the address verification letter from Google may take several weeks.
So, I would like to put in the domain that I think that I'm going to use. Can I do that, even though I don't own it (yet)?
Do they check if it's registered? Or are they just saying that it won't work because I can't access the HTML (yet)?
Do not register yet if your website is not ready.
Google will manually check your site whether it is eligible for Google AdSense. If they don't see any or poor content, they will decline your site and you will have to wait several weeks, maybe even months to re-apply for the same site. What you should do is finalizing your website until it's 100% ready, put content on it, and – most importantly – drive some visitors to it. At the very beginning you won't earn much anyway when you only have a little amount of visitors. When your website gets more popular, you should apply for your site and in most times your website gets approved in a few days.
You then have to wait for the letter, that's right – but you can already create ad tags, show them on your site and earn money like any other AdSense user. The letter is sent for verification and you can't request a payout before you didn't verified your address and bank account, but you will have to wait for $100 anyway (or the equivalent in your currency) since that is the minimum payout. After you achieved $100 at the end of a month, you will have to wait an additional 21-23 days to see your payment in your bank account.
So finish your website, put content on it, register for AdSense. You can wait for the letter while you already see earnings in your account.