Is it possible to check how many subscriptions a channel has made?
I have been looking around in Youtubes API without any success.
Note: I am not looking for the amount of subscribers but the amount of subscriptions.
https://www.googleapis.com/youtube/v3/channels?part=statistics&id=ID&key=KEY
The above call returns for example the amount of subscribers which I don't need.
You can use the following request to get the subscriptions made by channel. As you need only count I'm using part=id.
https://www.googleapis.com/youtube/v3/subscriptions?part=id&channelId={YOUR_CHANNEL_ID}&key={YOUR_API_KEY}
Then look for the 'totalResults' attribute to get the count of subscription made by the channel
Related
I'm in the process of upgrading an existing iOS IAP subscription system that already makes use of App Store Server Notifications. My existing solution is using the now deprecated latest_receipt, latest_receipt_info, latest_expired_receipt and latest_expired_receipt_info fields. According to Apple, these fields are now all replaced with the single unified_receipt field.
After watching all the required WWDC videos and sifting through the little documentation available I'm still left with a few unanswered questions.
The latest_receipt_info field is documented as:
An array that contains the latest 100 in-app purchase transactions of the decoded value in latest_receipt.
This means that this array will contain the customer's entire transaction history. This will not only include the relevant subscription but also any transactional products the customer may have purchased.
My question here is how can I find the relevant transaction in this array? The relevant transaction in this case would be the one that triggered the event (e.g. CANCEL). I need this transaction in order to update our backend database to reflect the current subscription status. For example, to update the subscription end date to the cancellation_date on a CANCEL event .
I have a similar question regarding the pending_renewal_info array. It's unclear to me from the existing documentation if all customers with an active (or maybe even expired?) subscription will always have an entry in this array.
An array of elements that refers to auto-renewable subscription renewals that are open or failed in the past.
I also need to find the relevant transaction in this field to do things like toggle the subscription status on a DID_CHANGE_RENEWAL_STATUS event or update the billing status on a DID_FAIL_TO_RENEW event. From the docs it doesn't look like there is enough info in the pending_renewal_info alone to compute the current subscription renewal status.
Overall my question really boils down to:
Can I be sure that there will be an entry in both unified_receipt.latest_receipt_info and unified_receipt.pending_renewal_info that matches the top level event auto_renew_product_id? And if so how should I find the relevant object in the respective array? Will there only be a single entry for each auto_renew_product_id or should I search the array and pull out the first match?
I found out that the transactions inside unified_receipt.latest_receipt_info array are ordered by purchased date from the latest to the oldest. And sure that you can found out the the top level event auto_renew_product_id.
However, for updating the subscription status or billing status, I utilize the return value from /verifyRecipt, which you can get by requesting to the Apple verifyReceipt server with receipt-data and password(https://developer.apple.com/documentation/appstorereceipts/verifyreceipt). Noted that the input receipt-data is unified_receipt.latest_receipt, and the responses share the same structure as unified_receipt.
We get the user cancels in the next 30 days from our database and we call to Apple one to one
https://buy.itunes.apple.com/verifyReceipt
We want to call for a list of user cancels in the next 365 days which can be a huge list.
I look for that in the documentation and in google but I couldn't find if there is a limit on the number of requests to Apple.
Does anyone know that?
After contact Apple's support, there are not query limits.
I have this endpoint implemented several months ago and I make a huge number of requests every day without any problem.
It's the only way to verify the status of each receipt because their webhook doesn't seem reliable.
I would like to know it is possible to get usage records for a twilio number.
It seems the api returns usage for a twilio account only.
https://www.twilio.com/docs/api/rest/usage-records#usage-categories
Twilio developer evangelist here.
Data from the Usage Records API are aggregates for an entire account, not at the phone number level.
You could use the Messages and Calls resources to calculate your own usage though. You'd need to collect all the messages sent to the number and from the number and similarly collect all the calls made to the number and placed from the number.
If you are trying to collect this data in order to charge a customer, then can I recommend using subaccounts instead. Then you can use the usage records on the subaccount and just get the details you need.
Hello I have a monthly subscription on my app using Braintree which is working ok. I would like some advice on best practices for the event where payments aren't made on time for whatever reason.
I currently have a User model with subscribed:boolean subscribeddate:date and subscribedend:date.
When a user completes payment through braintree, the attributes get updated to subscribed:true subscribeddate:Date.today and subscribedend:Sometime_way_in_the_future .
When a user cancels a subscription, the attributes get updated too, subscribed:false and subscribedend:(a braintree attribute, billing_due_date)
This way I can filter things in my app according to dates and subscription status. The only problem I can see with this is if Braintree tries to charge an account one month but fails. Braintree has an attribute for this (.days_past_due), but my app has no way of knowing whether this has occurred or not.
What are the best practices for this? Should I do a scheduled task each day to check if every single user has a value for the .days_past_due attribute on the Braintree server? Would this not be incredibly slow if I have a lot of users?
I may be going about this all wrong and I'd just like a bit of advice on the matter,
Thanks.
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact support#braintreepayments.com.
Your best bet is going to be to implement Braintree's recurring billing webhooks. Webhooks send you a notification via HTTP POST whenever an event occurs that may not have been directly triggered by an API call—such as a customer getting charged via their subscription, a subscription getting canceled, or a subscription going past due. This will allow you to directly respond to subscription events, without having to perform daily checks to see if any changes have occurred.
To use webhooks, you need to choose which events you want to receive webhooks for, designate an endpoint on your server where we'll send the notifications, and set up that endpoint with code to parse the webhook notification into a useable form. For details, see this guide with instructions.
On the getting started page for Apple Pay, it says that Apple Pay supports "partial shipments." How is this implemented in practice? I know how to get a token from a successful PKPayment. Once I get that token, how do I use it to implement multiple sub-order payments through my payment gateway?
For example, say the user validates a total $100 purchase through Apple Pay of two separate suborder shipments ($40 and $60 each) and I now have an associated token for the $100 order. Because of restrictions on some networks, we can't capture each payment until the associated item has been shipped, and they ship at different times.
Do I have the ability to authorize and capture payments of any amounts using that token?
What is the best approach to authorizing and capturing those sub orders?
Do I auth for the total ($100) and then auth for each sub total ($40, $60) at shipment and then capture for each sub total? If so, then I will be potentially authorizing more than the necessary total ($200), and that doesn't seem right. Is it valid to just skip auth for the total, auth for each sub total, and then capture the sub totals as they ship?
You can't capture an authorization more than once. For stripe you would need to save the token to a customer, and charge the customer for each shipment separately. This isn't only the best way it is the only way to do it.
Once you have a token and attach it to the customer object in stripe, you have the ability to charge it at any time & any amount up until the expiration date or if they remove the card from their apple pay account, like you would any other card regardless of the initial authorization.
The rest of your questions will vary by opinion as there are different ways of doing it, but here is how I would charge this type of order. I think this method benefits both the business and the customer, in addition to keeping stripe/apple happy. This isn't apple pay specific, I would treat most orders with these requirements the same. Also keep in mind apple pay supports it, but it is not required. You can collect all up front regardless of shipment dates.
Generate token from PKPayment for $100
Create customer(if needed) & add token to customer
Create charge against customer using that card for $100 without
capture
Within 7 days assess expected shipping dates.
Once assessment is complete immediately capture only the amount
expected to ship within a week on the initial charge. In your
example this is where I would capture $40 for the first charge. If
nothing is expected to be captured issue a complete refund.
Any shipments beyond the 7 days, create individual charges for the
shipments using the customer object, not the token. Again in your example this is when the $60 shipment goes
out charge that here.
As long as the second shipment charge doesn't happen to go out earlier than the 7 days this would prevent any authorizations overlapping resulting in holds of more than the initial amount at any given moment. I would treat almost any transaction like this apple pay or not.