You could set a fixed fee, but then you'll run out of visas by the end of the year.
It sounds like your fee is too low.
Seriously though, set the price as some function of remaining time and remaining items (example: p = C*d/n, where d is days remaining, n is items remaining, and C is a constant.) If someone wants multiple items, the price is just the sum of the prices for that many items purchased individually.
Auction off VISAs once a year, price them at the median of the winning bids, and allow the winners to resell them for at most 10% more.
Sell 180 visas per day over 6 hours between 9am-3pm for 361 days of the year. A new auction every two minutes of one visa. Final day of the year sell remainder of visas and take four days off until new year.
Start Jan 1 and say Google bids $10000 x 10 visas. They win the first ten auctions over the first 20 minutes. The reference price is set at $10,000 for auction #11.
But $10,000 is too high for the next bidder who wants to pay $9000. No sale on auction #11.
Auction #12 starts with 2 visas for sale. You decrease the reference price by 2/180.
So new min reference price is $9888 and there are two visas for sale. If no sale we move to 3/180 decrease for next round.
Down to $9724 and three visas for sale. Keep repeating this decrease until the price reaches the next highest bid.
As prices decrease with each unsold round buyers who are looking for, say, six visas for the year would see prices that are perhaps higher than they'd like but they can get all six visas bought in one lot.
If a sale occurs of any number then the next round doesn't decrease in price.
Bidders can bid for any number of visas at any price at any time of the year. There are always 180 new visas up for sale every day. If some big company wants 1000 visas and is willing to pay then the first 1000 auctions go to them at their price point.
By only decreasing the price by the percentage of unsold, it stops large price drops. You can set a minimum figure it never goes below.
Big businesses might want 200, 500, 1000 visas and be willing to play the auction to see if they can get a good price. So if they log in on day 50 of the year and see 140 visas for sale at $5000 each, they might buy all of them just to guarantee they at least get 140.
Then two minutes later there is 1 visa for sale at $5000 and the bidding keeps going.
Carryover any unsold and add it to the total. If 30 carry over then the next day has 210 visas for sale. First auction of the say is 30 unsold + 1 new. If no sale the new cost cut is 31/210 x reference price.
If the first 10 visas went for $10K each and then there was no sale until auction number twenty, you'd see the price drop to $7363 at ten visas for sale.
If a single business just wants one, they have an opportunity to buy at $7363. Or they can toss their bid in at $5000 and let it simmer to see if the reference price ever drops to $5000.
~ I have zero idea what these visas go for by the way so plug in whatever figure is closer to reality. If the gov wants $20K min then that's the min price. Jan 1st 9am the auction opens, you'd see the price rise to $32K and sold. Then $33K sold. Then no sale, drop of 2/180 x reference price and so on.
This question is just for my interest. Suppose you, the US government, have a finite supply of 65k H1B visas that you're prepared to offer per year, and you want them to go to the most economically valuable applicants. You could set a fixed fee, but then you'll run out of visas by the end of the year. You could have a blind auction every few days, but then companies have to wait until an auction happens to be certain of the outcome. It seems like instead, it should be possible to set a dynamic fee, that always offers a company a price to purchase any number of H1Bs (less than the total amount remaining), but that ensures that a number near to the total are offered per year?
To summarise, and abstract away the details of the scenario, I'm looking for a mechanism that works for the case where there is a finite supply of n items that has the following properties:
Presumably there's some intersection of queuing their and mechanism design that is designed to answer such a question?