Is it possible to do an in-app purchase of a consumable per quantity in a windows store or windows phone 8 app? For ex: If the consumable is of type 10 gold coins, can I initiate a in-app purchase of 2 10 gold coins or 5 10 gold coins?
No, it is not possible to specify a quantity along with the product Id for a purchase currently (reference). To address this, most applications just offer the consumables in various quantities (1, 10, 25, 50, 100, etc.).
While you may be able to create a lop that purchases and verifies each quantity, I'd suggest the more reliable would be to just make a single purchase of a larger predefined quantity.
you are need to perform in app purchase shown here and you can implement one purchase at a time.
Related
I recently discovered Poloniex's API and am a big fan. I am puzzled about the following thing though: I query one Poloniex's BTC-ETH trade history for a 24h trading period. E.g., https://poloniex.com/public?command=returnTradeHistory¤cyPair=BTC_ETH&start=1489190400&end=1489276799 queries all BTC-ETH trades on March 11, 2017 (UTC). The returned JSON contains 46,675 trades (below the API's max result size of 50k). When counting up all the sell- and buy-trades contained in this JSON, I see that there is a total of 8,814.124270 coins bought vs 7,754.184259 coins sold. How can that be? Shouldn't those two numbers be the same? What am I missing?
Thank you very much in advance.
A buy is when someone buys the ask, also known as an uptick.
A sell is when someone sells the bid, also known as a downtick.
Everything that is stuck on the book is considered liquidity. Market price buyers and sellers remove liquidity. People who put orders on the book add liquidity.
So no, the buys should not equal the sells as it is totally possible that all that happened one day is that everyone kept hitting the buy button.
Consider this, if the buys equalled the sells, why would you need the data sent twice, and how would you know whether the bid or ask was taken?
Im trying to build a hotel application system and now i have laid out plans for the DB. My requirements are a guest searches for availability for a room. A room could either be king or queen, and smoking or non smoking. Also the guest enters the check in and out date. Based on the search the guest enters their info and reserve a room. Based on the reservation the service agent receives the receipt(reservationId). The service agent books the room upon receiving the reservationId. A guest can reserve several rooms per reservation. Now below is how my DB looks right now.
My question is since a guest can have several rooms per reservation how could i represent multiple rooms per reservation. Note: This will be done using hibernate. And below is my actual setup now for my DB please feel free to correct me if my approach is wrong: Below is a draft of how my db looks:
Reservation(resId(PK), checkIndate, checkOutDate, roomType, roomProperties, guestId(FK)).
Guest(guestId(PK), fname, lname, email, license, address_details).
Room(roomId(PK), roomNumber, roomProperties, roomType, price).
Booking(bookId(PK), resId(Fk), roomId)
RoomOccupied(bookId(PK and FK), roomId(PK and FK), flagChecKIfOccupied(default value is 0 if not occupied or 1 if occupied)
Payment(paymentId(PK), resId(FK), finalPayment)
What is the best way to find out if a customer has purchased a product instore, as a result of visiting the website? Would a membership card be a good idea, or something like an email newsletter with offers for that specific store? Keeping in mind, the product may only be bought less than a handful of times in a few years.
If you give a product a unique code, in addition to it's web id. The unique code could only be redeemed instore in exchange for a free gift or instore only discount. That way the volume of sales can only be attributed to the unique code!!
Volterony
I am selling a high volume product that costs a minimal amount per piece. ($0.001 USD each to be exact).
I allow my customers to purchase a one time amount of product or a recurring payment amount of product at their desired choice of USD per payment.
How can I limit my customers to only spending $10 USD or more per payment through PayPal? They limit it at $10,000 USD, can I limit it at $10 USD?
Right now, I am not processing payments of less than $10 USD, and recommending that customers do not, but it is still possible to make them.
The problem arises when a customer purchases $1 worth of product and paypal takes 40 odd percent of that payment due to per-payment fees.
I do not believe PayPal offers a setting for minimum allowed payment. This is something you would need to handle on the server side. It would be easy enough to do. Just don't display the "Pay with PayPal" button unless the order total is $10 or more.
I'm building a website and I'll be charging my customers to use it. I'm thinking of having 6 monthly or yearly licence options and there'll be a few different variations of licences available each granting different types of access to the site.
Also I'll have a few optional extras that you can add on to the purchase of their licence. These would be once-off purchases more like products rather than licences. They're more add-ons for the website that enable more features. Once purchased you get to keep it. So everything's based on the site there's no shipping to worry about.
This will be displayed in some sort of shopping cart fashion where they can choose what they want then sent through to Paypal for processing.
Just wondering how I would model this correctly in my database? So far I've come up with:
Database schema
Basically I've tried to put licences and products in the same table and used a flag column (licence_or_product) to distinguish between the two. This would help in the display on the website about whether it's a product or licence.
Is it worth having the licence *offering_start_date* and *offering_end_date* fields? I'm trying to get it so that I can expire that offering if I want to make a new licence offering with a different price. That way customers who have already purchased the licence at that price it always stays at that price. If I want to change the price, I'll set the offering end date to today, then make a new licence_products row with a lower price but end_date in the future. Is that the right way to do it? Or do you just edit the price of the item directly? I'm just thinking if the price changes then the customer wants a refund for that licence, how do you track how much they paid for that licence? The amount_paid field would tell me how much the whole order cost but not the original price of the licence which has now changed. Do I need a history of all the product price changes?
Other thing I don't know how to do, lets say they've purchased a licence to use the site for a year. How do I pull out which is the most current licence? Lets say I've started them off with a 30day trial licence, then they purchase a yearly licence. Do I invalidate the trial licence immediately? I think I only want one valid licence at a time. So if they buy another licence before the old one expires I'm not sure how my program should handle that.
Any help much appreciated. Thank-you!
P.S. Here's the SQLyog database schema and SQL if you want to have a go at reworking it a little.
sql db extract
SQLyog schema
I think you should create the following 3 tables:
1. customer (client or whatever make sense to you),
2. license and
3. customer_license.
And I suggest the following fields for the customer_license table:
id (some int auto_increment)
customer_id (some int) FK
license_id (some int) FK
price_offered decimal(7,2) (with the precision you need)
expiration_date date
active tinyint(1)
created_at datetime
updated_at datetime
This way you can track all details of the customer with the license you offered them: what you offered? when you offered? when does it expire? price offered? the license is active?
Good luck