Aptimus Advertiser Specifications

Order Processor Validation

Back End Validation
The back end validation attempts to prevent malicious users from inserting bogus data into our system. Where the front end attempts to help the user enter correct data, the back end prevents the system from accepting invalid data and will not persist the order until valid information is provided.

Objectives for Back End Validation:

Check for required fields.
Check that at least one order exists.
Check the value against any word exclusion for the specific question.
Check for and apply the value to any rule associated to the offer question.
Check that an answer is within the acceptable range of answers.
Check generic field names and values.

Required Fields
Back end validation's first task is to get a list of required questions for the particular offer. If a question is required then an answer must appear in the order. If there is not entry for that question, then the order is invalidated.

At least one order exists
The validation must find at least one order associated to a valid offer.

Word Exclusions
Word Exclusion is a fancy way of saying that we filter out foul language and obvious "fake" answers to questions. Word exclusion is NOT associated directly to offers. Instead, they are associated directly to the defined question. An example would be that first name cannot be "crap". This word would not be allowed in any offer that uses first name in it’s set of questions.

Word Exclusion is implemented using word lists. The word, "dick" may be short for Richard and be allowed in the first name, however, we may decide to exclude it from city. But both of those questions may want to exclude the word, "fart". We do this by having separate lists. Both lists would contain the word "fart" but only the list that is associated with city would also have the word, "dick".

The words used in word exclusion are not case sensitive. If the word "blah" is defined in a list for exclusion, then the question will reject "BLAH", "blah", "Blah", "BLah", "BlAh", etc.

Offer Question Rules
Rule validation is a fairly complex system. Validation rules are associated at the offer question level and not at the question definition level. Meaning that if a rule applies to first name in one offer, the same rule will not apply to first name in another offer unless it was explicitly assigned that rule for both. There are three main types of rules:

Question to Value
Question to Question
Question Value to Question Value

Question to Value
When an offer question is given a rule based off value, it is basically saying that the value given for the question must be equal, not equal, greater than, or less than a specific value. An example would be that Loan Amout must be greater than $20,000; or Age must be less than 17; or State must be equal to CA.

Question to Question
When an offer question is given a rule based off question to question, it is forcing the value of the question to be equal, not equal, greater than, or less than the value given in another question. An example would be that hobby1 must not equal hobby2; or password1 must equal password2; or that Loan Amount must be less than Monthly Payment.

Question Value to Question Value
This one is hard to explain so I'll just give an example and hopefully you'll understand based off that. If the Credit Card Type given is VISA then the Credit Card Number must start with 4. If the Type is Discover then the Number must start with 6011. Basically this rule combines questions but they have different values. These values go hand in hand but are not necessarily equal to themselves.

Range Test
For each answer, if the question is required, it must abide by the range of answers stored in the database. If there is not range found in the database, then the answer is considered valid for this test and skipped. If a range is found, such as M or F for gender, or for a list of state abbreviations, then the answer is matched to each valid answer until a match is found. If a match is not found, then the answer is considered invalid and the order is not accepted.

Field Names and Values

First Name

First Name must start with alphabetic character followed by any letter, number or symbol.

Last Name

Last Name must start with alphabetic character followed by any letter, number or symbol.

Credit Card

First we check that only numbers are used.
We check to make sure the number is at least 14 characters in length.
We use an algorithm that converts every other character in the credit card number to a different number based on whether it's odd or even and adds all the numbers together, and if the result divided by 10 is not equal to 0, the number is invalid.

Address

State must be 2 upper case characters and be one of the items listed in the database for that attribute option.
If state alone appears to be valid, then state and postal code are compared together against 3-party address data to verify they are a valid combination.

Email Address

Email Address must be alphanumeric and/or symbols followed by an @ symbol followed by more alphanumeric and/or symbols followed by a period and then ending with at least 2 alphanumeric characters before the end of the string.

Phone Number

The Phone Number must be either 7 or 10 digits.

Gender

Gender must be either M or F.