CasperVend 2/Gift Cards/V3/Black Friday Update: Difference between revisions

From CasperTech Wiki
Jump to navigation Jump to search
No edit summary
 
(12 intermediate revisions by 2 users not shown)
Line 3: Line 3:
The "Classic" distribution method is the closest to how the older V2 cards worked, but has the unfortunate added requirement that the customer has to rez their cards in order to activate them. This really isn't ideal, but it's required to protect against a known no-copy cloning exploit. Even with this protection, however, there are still ways to clone these cards before activation.
The "Classic" distribution method is the closest to how the older V2 cards worked, but has the unfortunate added requirement that the customer has to rez their cards in order to activate them. This really isn't ideal, but it's required to protect against a known no-copy cloning exploit. Even with this protection, however, there are still ways to clone these cards before activation.


Therefore, we always '''highly''' recommend that merchants use the "Modern" method, which is 100% secure against any in-world cloning because it's strictly enforced by our servers.
Therefore, we always '''HIGHLY''' recommend that merchants use the "Modern" method, which is 100% secure against any in-world cloning because it's strictly enforced by our servers.


Here's how the "modern" method works:
== '''Here's how the "modern" method originally worked''' ==
:* A customer paid a vendor to purchase a configured gift card product
:* The customer was delivered an empty gift card (L$0 balance)
:* When they wore the card, the system allocated the credit from the purchase to the card.


* A customer pays a vendor to purchase a configured gift card product
'''However, this process has had some drawbacks.'''
* The customer is delivered an empty gift card (L$0 balance)
* When they wear the card, the system allocates the credit from the purchase to the card.


However, this process has some drawbacks.
:* If a customer purchases multiple cards at once, and doesn't wear them in the order that they bought them, the system might allocate the wrong balance to the wrong card.
:* The oldest pending credit would be applied to the card - which would confuse customers who forgot about an earlier gift card purchase.


* If a customer purchases multiple cards at once, and doesn't wear them in the order that they bought them, the system might allocate the wrong balance to the card.
== '''As of 2022-11-25, the "Modern" algorithm has a new process to address these issues''' ==
* If a customer purchased a gift card a long time ago, but forgot about it, they may receive an amount they weren't expecting (because the system is applying their credit from ages ago).


Now - when NOT in "precocious" mode - a more intelligent algorithm is used:


'''As of 2022-11-25, we have updated the Modern algorithm to hopefully address these issues'''.
:* '''Parsing the name of the gift card:'''
:: If the gift card object name is, for example, "My amazing 100 L$ gift card", the system will identify that the card is supposed to have a L$100 value, and it will search first for a credit of that value to apply to the card. This is designed to be flexible, so "500 L$", "500$", "$500", "L$500", "500l", "500L", "L500" or even just "500" will all cause the system to search for a credit with a value of L$500.


Previously, the system simply searched for the oldest pending credit and applied that to the card.
:* '''Parsing without monetary symbols:'''
::In the case of numbers without any "$" or "L" symbols, the system will sort the numbers in descending order (largest number first) before attempting them. Therefore, if a card's name is "My TOP 10 GIFT CARD 100", the system will try L$100 first before trying L$10.


Now, a more intelligent algorithm is used:
:* '''Credits from the last hour'''
:: Next, if no match was found, the system will search for gift card credits '''from the past hour''' in ascending order (oldest first).


 
:* '''Credits older than one hour, newest first'''
:* Firstly, the gift card name is parsed.  If the gift card object name is, for example, "My amazing 100 L$ gift card", the system will identify that the card is supposed to have a L$100 value, and it will search first for a ::credit of that value to apply to the card. This is designed to be flexible, so "500 L$", "500$", "$500", "L$500", "500l", "500L", "L500" or even just "500" will all cause the system to search for a credit with a value of L$500.
:: Next, if no match was found, the system will search for older credits (older than one hour ago) in DESCENDING order (newest first).
 
::In the case of numbers without any "$" or "L" symbols, the system will sort the numbers in descending order before attempting them. Therefore, if a card's name is "My TOP 10 GIFT CARD 100", the system will try L$100 first ::before trying L$10.
 
 
:* Next, if no match was found, the system will search for gift card credits '''from the past hour''' in ascending order (oldest first).
 
 
:* Next, if no match was found, the system will search for older credits (older than one hour ago) in DESCENDING order (newest first).




This should hopefully result in customers almost always getting the gift card credit that they expect to receive!
This should hopefully result in customers almost always getting the gift card credit that they expect to receive!

Latest revision as of 23:14, 25 November 2022

The introduction of the CasperTech V3 gift cards in 2019 brought a significant and much needed improvement in security.

The "Classic" distribution method is the closest to how the older V2 cards worked, but has the unfortunate added requirement that the customer has to rez their cards in order to activate them. This really isn't ideal, but it's required to protect against a known no-copy cloning exploit. Even with this protection, however, there are still ways to clone these cards before activation.

Therefore, we always HIGHLY recommend that merchants use the "Modern" method, which is 100% secure against any in-world cloning because it's strictly enforced by our servers.

Here's how the "modern" method originally worked

  • A customer paid a vendor to purchase a configured gift card product
  • The customer was delivered an empty gift card (L$0 balance)
  • When they wore the card, the system allocated the credit from the purchase to the card.

However, this process has had some drawbacks.

  • If a customer purchases multiple cards at once, and doesn't wear them in the order that they bought them, the system might allocate the wrong balance to the wrong card.
  • The oldest pending credit would be applied to the card - which would confuse customers who forgot about an earlier gift card purchase.

As of 2022-11-25, the "Modern" algorithm has a new process to address these issues

Now - when NOT in "precocious" mode - a more intelligent algorithm is used:

  • Parsing the name of the gift card:
If the gift card object name is, for example, "My amazing 100 L$ gift card", the system will identify that the card is supposed to have a L$100 value, and it will search first for a credit of that value to apply to the card. This is designed to be flexible, so "500 L$", "500$", "$500", "L$500", "500l", "500L", "L500" or even just "500" will all cause the system to search for a credit with a value of L$500.
  • Parsing without monetary symbols:
In the case of numbers without any "$" or "L" symbols, the system will sort the numbers in descending order (largest number first) before attempting them. Therefore, if a card's name is "My TOP 10 GIFT CARD 100", the system will try L$100 first before trying L$10.
  • Credits from the last hour
Next, if no match was found, the system will search for gift card credits from the past hour in ascending order (oldest first).
  • Credits older than one hour, newest first
Next, if no match was found, the system will search for older credits (older than one hour ago) in DESCENDING order (newest first).


This should hopefully result in customers almost always getting the gift card credit that they expect to receive!