Generate Amazon Gift Card

[Kusi Bertoldo]

TheIncentives API lets you create and distribute Amazon Gift Card claim codes quickly and as your business needs them.You can buy Amazon Gift Card claim codes using a web service, and can distribute these codes to your customers in a way that suits your business. This document describes how developers can use the AGCOD API to create Amazon Gift Card claim codes. You can use these codes in many ways, including (but not limited to):

Your code makes signed HTTP POST requests to our endpoints to create or cancel claim codes. (We do not accept SOAP requests.) The body of your HTTP requests will contain JSON or XML.Every request to an Incentives API operation endpoint must be digitally signed using your Incentives API security credentials and the Signature Version 4 signature algorithm."

The CreateGiftCard operation creates a live gift card claim code and deducts the amount from the pre-payment account. The response contains details you must store.The creationRequestId value uniquely identifies each creation request, along with other details like the amount, currency, etc. (in addition to the meta-data about that request, authentication info, etc.)To perform this operation, the following steps must occur:

This operation is idempotent, so if the Incentives API receives more than one request with the same creationRequestId, only the first request will result in the creation of a new gift card, and all subsequent responses will return the same original gift card. They will not be treated as different transactions.

Both CreateGiftCard and CancelGiftCard operation are idempotent, so if the Incentives API receives more than one such request with the same creationRequestId, then the first request will result in the creation/cancellation of the gift card request, while all subsequent responses will do nothing, and will not be treated as a unique transaction.

If you are integrating into the AGCOD API with the aim to resell the gift codes onto other businesses, you'll need to enter our reseller program. This is simple to do and more information can be found by contacting our account management team here. When you are up and running, you'll need to add a programID to the CreateGiftCard request as a mandatory field.

The programID is a pre-defined field which is generated when you add one of your clients to the Reseller Program in the Amazon Incentives Portal. The programID is then approved by Amazon. The programID is alphanumeric and can be up to 100 characters in length. You can use the programID field to help track client and use case transactions.

To assist you in the development, we have included a test example with fictitious Access Key/ Secret Keys to generate a known-answer test for different stages of the signing below. Details on how to perform each stage of the signing can be found here. Also see this diagram of the process.

Every response sent from the Incentives API has a status element that describes the execution status for the particular operation; there are three statusCode values: SUCCESS, FAILURE, and RESEND. See Error Handling for details.

We have provided mock error request IDs to simulate certain error responses with the (Create/Cancel) calls. When simulating an error response, the mock error request ID will need to be passed in to the creationRequestId field, similar to a normal request ID. The values passed in for the rest of the fields will simply be echoed in the response. To simulate a successful response, the value of F1000 can be passed in for the mock error request ID. See Mocking test examples and Error Handling for details.

Gift Card Claim Codes have monetary value and need to be treated very securely. We recommend having controls in place to ensure safe and secure handling of sensitive data (gift card claim codes, security access credentials, etc.). This includes defining proper audit controls on the file systems/databases where sensitive information is stored. You should periodically change the password of your Incentives API Portal accounts that have access to secret key credentials. We recommend rotating your access keys at least once every 90 days (3 months). The Incentives API Portal lets you generate a new access key at any time. *However, AGCOD does not support automatic key rotation.

I recently posted this question about codes for a gift-card-like voucher that users can redeem online. I wanted to find the best tradeoff between large keyspace, low guessability, and human readability. Now that I'm into implementation I realize I've got another problem altogether, more of an algorithmic challenge.

My first approach is to number all possible codes from 0 to 308,915,776, then start generating random numbers in that range. This obviously has a big problem though - I have to check my random number against all previously generated voucher codes and if it collides with an existing one I'll have to discard the code and try another. As the system accumulates more data it will slow down. At the extreme when there is only one code left it will be nearly impossible for the system to guess it correctly.

I could pre-generate all codes and shuffle them, then consume them in order. But this means I have to store many codes, and in fact my keyspace is bigger than the one i described, so we're talking about a very large amount of data. So that's also not too desirable.

So this leaves me with using the codes sequentially. I do not want guessable voucher codes though. The user who buys voucher "AAAAAAAAAY" should not have a good chance of getting another valid code if they type in "AAAAAAAAAZ".

This is definitely way less guessable. But they're still only one character off from each other, and given just two of these vouchers you would know which position is incrementing, and you would have a 90% chance of getting the next code in 24 guesses or less.

My "escape hatch" is to ditch all this and go with GUIDs. They have more characters than I wanted my users to have to type in, and contain similar characters like I/1 and O/0, but they magically make all of the above headaches go away. Still, I'm having fun thinking about this, maybe you are too. I'd love to hear some alternate suggestions. What have you got?

The likelihood of two randomly generated code colliding is basically the same as a user guessing a valid code - and you cannot prevent users from guessing. So you must have a key space so much larger than the number of actually used codes that random collisions are extremely unlikely as well (though, thanks to the birthday paradox, probably not unlikely enough to ignore them completely, at least if you want your codes to be reasonably short), and checking against existing codes and re-generating in case of a collision is a perfectly viable strategy.

Use an N-bit serial number R, combined with an M-bit hash H of the concatenated pair (R, S) where S is some secret "salt" S which you do NOT publish. Then encode the pair (R,H) alphanumerically in any reversible way you like. If you like algorithms like MD5* or SHA, but the bit count is too high, then just take the M least significant bits of a standard hash algorithm.

*before someone says "MD5 is broken", let me remind you that the known weaknesses for MD5 are collision attacks, and not preimage attacks. Also, by using an unpublished, secret salt value, you deny an attacker the ability to test your security mechanism, unless he/she can guess the salt value. If you feel paranoid, pick two salt values Sprefix and Ssuffix, and calculate the hash of the concatenated triple (Sprefix,R,Ssuffix).

Some random number generators have an interesting property: Used right they do not generate duplicate numbers in a long time. They produce something called a full cycle.Use one of the algorithms described there, seed it, and you will have many unique numbers,

The book shows that if you generate m random numbers with value less than n, the simple approach of generating numbers and throwing out duplicates will generate no more than 2m random numbers if m I read the whole comment and I found out something many people in other to protect use very clever and sophisticated means. the chances of getting a guess on my algorithm is 1/2600000all you have to do is to change the salt prefix salt suffix after each generation

Ideally the best way would be to choose a sequence long enough so that you can safely assume if there will be any duplicates. Do note that, perhaps counter-intuitively, this happens more often than you think because of the Birthday problem.

So, it all depends on how many you want to generate, and the maximum length of the code you're comfortable with. If you are generating many and you want to keep it short, you should save the ones you previously generated, and check against the database for duplicates.

Random numbers are unguessable but not necessarily unique. The numbers produced by various algorithms are unique but guessable (the algorithm can be reverse-engineered). I don't know of a single algorithm that gives both properties, and because of the need to defy reverse engineering, it falls in the domain of cryptography. Non-experts, of course, shouldn't try to design cryptosystems.

Fortunately you don't have to get both properties from the same algorithm. Your gift card codes can consist of two parts: a part that is unique (generated using a linear congruential generator, perhaps, or modulo arithmetic, or even just an integer that you increment each time) and a part that is unguessable (just random numbers).

You want to generate a sequence of numbers that together form a permutation of S = 1, ..., MAX. One way to do this is to take the elements of a cyclic group over S. For example, the numbers R = x modulo p, x^2 modulo p, x^3 modulo p, ..., x^(p-1) modulo p form a cyclic group over 1, ..., p-1, provided p is a prime and x is coprime to p. So if you choose MAX as a prime number you do use this sequence.

You want a "tough-to-crack" sequence. A generator for the sufficiently-tough-to-crack sequence is called a pseudorandom generator (ofcourse you probably don't need that tough-to-crack). An example is the last digit of elements in R above, provided p is kept secret (am I correct?). But the answer by Andreas already uses a source of (pseudo-) random numbers, so cannot be called a pseudorandom generator.

3a8082e126