OK, database geek hat on here. It's not too hard to pregenerate a set of every possible ticket combination, just lots of cross joining of numbers tables and a bit of coding of the play rules. Add in the payout rules and you can produce a total set of all possible cards along with the payout for each given card.
From this set, we can select exactly the number and balance of paying and non-paying cards we want, chosen pseudorandomly from the set of possible cards. Output that set and sort that pseudorandomly, then send to the printers. You've got a (pseudo) random selection of cards with an absolutely controlled payout pattern.
The downside, and what seems to be the critical problem for the suppliers, is that I suspect you'd have less 'near miss' cards this way to entice players. But it's absolutely possible to ensure that you have a defined payout pattern while also giving random ticket distribution.
I don't think you've done the math yet on how many possible ticket combinations there are. I have more reason than most people to spend time thinking about bingo math. Get out a piece of paper and run some calculations: enumerating the whole solution space is not feasible.
Anyhow, the real solution is easier: checking a bingo card or lottery ticket for any feature you want is, essentially, O(1). Generating a lottery ticket is O(1). Generate billions, sort into piles, choose millions from piles in proper proportions, randomize order, done.
This still won't help you if you print sufficient information on the ticket to reverse engineer whether it won or not without actually purchasing it, of course.
I'm a Brit (and not a lottery player) so not fully familiar with US state scratchcard lottery game mechanics :-) The longest odds straight lottery over here is 75m to 1 which is definitely enumerable, but if you say these cards get into the billions and would crash my server then I'll believe you! Agreed that you can still generate a controlled prize distribution with random tickets generated individually rather than pregenerating all combinations - it's a bit more fiddly but perfectly doable.
All this I agree won't help if your card design is as poor as the original article was, but to address the complaint of the poster before me it's perfectly possible to randomly generate tickets while controlling the number of winning tickets - you just have to have a screening function which prevents more than your controlled number of winners making it through.
I've heard of this technique used for games of chance in vegas where they need to tightly control the outcomes both so they don't lose money but also to satisfy the reporting requirements for the regulatory commissions.
