I want to calculate total transaction fees paid by users by using a substrate-api-sidecar on any substrate-based chain.
I tried reading two docs on calculating fees but none could help me out in deducing what to look for while querying a block. Click here for document 1, here for document 2.
Would that differ from chain to chain implementation?
I checked Moonriver documents on using substrate-api-sidecar and it seems possible to calculate fees. But I could not find out how to do so against a Polkadot parachain(relay chain)?
For setting the base premise, Token Terminal states that in a blockchain, total revenue generated means total transaction fees paid by the users.
Related
I am using django-stripe to generate Stripe Checkouts.
I would like to pass the Stripe fees on to my customers ("surcharging").
I found a help article from stripe regarding this. It says in general how to calculate the fees to put on top of the price of the product.
The problem is, that different payment methods have different fees.
And when creating the Checkout, I must calculate the final price (including the fees I want to pass on) before I know what payment method the customer will select (and therefore what fees the customer will have to pay).
So I don't know the fees when I must put them on top of the price the user has to pay in the Checkout.
Is there a way out of this dilemma?
Unfortunately there isn't a way to dynamically change the price based on the payment method presently. You must specify the amount to be paid prior to redirecting your customers to the Stripe Checkout interface.
You could create make your users select a Payment Method prior to redirecting them to Checkout (restricting the payment_method_types to their selection) and adjust the price based on their chosen Payment Method. But that requires a lot of work on your side and loses some of the nicest features of Stripe Checkout.
One of our customers is experiencing an issue that I am trying to debug where their order is being marked as having a $0.00 SPLIT_CUSTOM entry for our custom tender. We are following the sample and making the payment amount as the full amount in the success response of our "TenderActivity", but sometimes the payment is marked as $0.00.
What could cause the split payment entry to be $0.00?
Here is an example:
This is what was happening:
A register transaction is started and the custom tender was launched (TenderActivity)
The custom tender would temporarily malfunction.
The cashier would take card from the customer and put it into the clover hardware. The custom tender would still be on the screen, but In the background the clover hardware processes the transaction and marks the order as PAID.
While step 3 was happening the custom tender would recover and mark the tender was having paid the amount.
This causes the TenderActivity to mark the payment as complete with the full amount plus tip if present.
Clover says the order has already paid because payment was taken on the hardware in step 3, marks the new payment as a SPLIT_CUSTOM and includes the tip if given. The amount paid by the custom tender is marked as 0.00.
In an application that has many 'shops' every registered admin user has a 'shop' entity, each shop sells items where each item belongs to a certain 'category'. Having multiple clients (100's in some cases) each client has an account to follow up on their purchases and past orders. Each shop generates invoices for their clients, clients pays the invoice.
Admin User -- > Shop
Shop ---> clients
|-> items Categories
|-> items
|-> invoices
|-> payments received
An admin page shows a report showing invoices within the year (from Jan to Dec) this page is a client requirement. The shop is able to manually generate a new invoice when a purchase is made, and records a payment when it is paid. Note: This all happens in the actual shop, there is no online client purchases.
As a single shop generates few invoices per month (~100's), and multiple payments per month (~100's), showing this per year easily goes to thousands entities to show on a single page.
To optimize loading the page and generating the sales year report (total sales, revenue, payment...etc.), we thought we'd structure the data in a way where each item category per year is also an entity. This means that whenever a purchase is made for an item in this category, we need to add the item's purchase price to the itemCategory at that year in this month.
itemCategory Model:
itemCategory(ndb.Model):
shopID = ndb.KeyProperty()
year = ndb.IntegerProperty()
monthly_sales = ndb.FloatProperty(repeated=True) #12 months
This way we can load the entire sales table by reading just the list of itemCategory for this shop for this year, instead of reading all individual purchases through the year. This would save lots of Datastore reads and decrease page load time on the expense of an extra read, sum & write to this summary like entity.
Category Jan Feb Mar ... Dec
--------------------------------------
Men's shoes 1000 1300 850 ... 1400
Kids shoes 600 850 650 ... 900
The challenge at this point is that strong consistency is quite essential, for individual purchases and for the itemCategory entities. Because if the shop tries to add multiple purchases in a successive short timed way, with eventual consistency itemCategory might have not been updated with the last purchase sum yet. Resulting in wrong sales values. Also the same for individual purchase if there was a requirement to edit one right after it was added, a query for the entity without its ID might have no results. So it seems that Ancestor queries is essential here with maybe the shop as the parent entity. Yet, this will result in a contention issue later on (at least until Datastore is migrated to Firestore) with all those entities (thousands in this case!) having one single parent!
The same goes for invoices, generating a new invoice means knowing the latest invoice number so that they are always in sequence without gaps. Querying invoice with eventual consistency may result in duplicate invoice numbers.
What is the optimum way to structure the data at this point for strong consistency? Unfortunately the project has been there for a few years, and was started using Google Datastore rather than Cloud SQL (which seem to be more appropriate for this kind of projects). Hopefully all these issues goes away after the migration to Firestore having Strong consistency for all reads
Consider exporting the data and then importing it into a Cloud Firestore in Datastore Mode project. No more eventual consistemcy issues.
There are certain ways you can achieve strong consistency.
Query using key. Whenever you try to read an object via its key it is strongly consistent.
Another approach would be to use NDB Asynchronous Operations. See related documentation here.
A really naive approach would be to provide a delay which could help you but the delay should be provided in such a way that it is sufficient for the object to get updated.
And the final approach could be to export data into Cloud Firestore. There you can achieve strong consistency always.
Hope this answers your question!!!
I was given an Amazon awsAccessKeyId and awsSecretKey,
also our company has affiliated with Amazon, we get a Associate Tag.
And I was told we may get higher API limits, because we are affiliated.
But I don't have any detailed info about the API limits,
I want to know how many calls i can make in a second
Is there any way I could check our API Key status?
The call i use will be check product info like:
Service=AWSECommerceService
&Operation=ItemLookup&ItemId=[ID]
&IdType=ASIN
.....
When you exceed the requests limit, Amazon Product Advertising API sends a (possibly gzipped) response with 503 status code. Example response for ItemLookup query:
<?xml version="1.0"?>
<ItemLookupErrorResponse xmlns="http://ecs.amazonaws.com/doc/2013-08-01/">
<Error>
<Code>RequestThrottled</Code>
<Message>AWS Access Key ID: YOUR-AWS-ACCESS-KEY-ID. You are submitting requests too quickly. Please retry your requests at a slower rate.</Message>
</Error>
<RequestId>fabebd87-54a2-44ec-b547-deb5feee900a</RequestId>
</ItemLookupErrorResponse>
The rules have changed since #at0mzk's answer.
You have to make sales to use the API. The limits are set by sales in the last 30 days.
Effective 23-Jan-2019, the usage limit for each account is calculated based on revenue performance attributed to calls (also called requests) to the Product Advertising API (PA API) during your account’s latest 30-day trailing period.
Each account used for Product Advertising API is allowed an initial usage limit up to a maximum of 1 request per second and a cumulative daily maximum of 8640 requests per day (TPD) for the first 30-day period after your account has been approved. Following that period, your PA API usage limit will solely be based on your shipped item revenue. Your account will earn a usage limit of 1 TPD for every 5 cents or 1 TPS (up to a maximum of 10 TPS) for every $4320 of shipped item revenue generated via the use of Product Advertising API for shipments in the previous 30-day period.
Docs
Apparently there's not way of checking exactly what those limits are and they will change based on the performance of your account.
It seems that the minimum rate limits are:
1 request per second
8640 requests per day
Those limits will increase if your account has a good performance (as in shipped items revenue) using the API links.
From: Amazon Product API - Troubleshooting
API Rates
Curious to know how we provision API call rates for Product Advertising API 5.0? First, some definitions:
TPS – Transactions per second, refers to the maximum number of API calls you can make in one second. Each API call counts as one transaction. For example, if you send 10 ASINs in the request parameter of a GetItems() call, it counts as a single transaction.
TPD – Transactions per day, refers to the maximum number of API calls you can make in one day. If Associate has 1 TPS and 8640 TPD, then maximum of 1 request can be sent per second and 8640 per day. Even if 1 TPS is there, once TPD is exhausted requests will be throttled.
Primary Account – This refers to the Amazon username (email address) and password that you used to create your Associates account and used to generate Product Advertising API 5.0 credentials.
Shipped revenue – This refers to the total sales volume of all items Amazon has shipped from orders resulting from clicks through links you created using Product Advertising API 5.0.
Also:
As soon as you create your Product Advertising API 5.0 credentials, you are allowed an initial usage limit up to a maximum of one request per second (one TPS) and a cumulative daily maximum of 8640 requests per day (8640 TPD) for the first 30-day period. This will help you begin your integration with the API, test it out, and start building links and referring products to your readers.
Your PA API usage limit will be adjusted based on your shipped item revenue. Your account will earn a usage limit of one TPD for every five cents or one TPS (up to a maximum of ten TPS) for every $4320 of shipped item revenue generated via the use of Product Advertising API 5.0 for shipments in the previous 30-day period. For correct attribution of shipped item revenue please ensure that you always call Product Advertising API 5.0 with the primary account credentials and retain all the URL parameters that the API returns in its response.
...
If you are trying to submit requests that exceed your account’s usage limit, or if your access has been revoked you will receive a 429 TooManyRequests error message from Product Advertising API 5.0. Please refer our API integration best practices to learn more on how to avoid these situations and optimally access the API.
I would like to get shipping costs of an order. I can get amount, customer information, purchase date of an order... but where is the shipping cost?
Any code or link would be very helpful.
Thanks.
Assuming that you are using the Orders API, the shipping charges for each item are stored in the shippingPrice property of the OrderItem type. You need to use the ListOrderItems operation to retrieve the order's items.
See page 26 of the Orders API documentation for a description of shippingPrice property. See page 25 for a description of the ListOrderItems operation.