The Basics

GiftRocker services allow partners to work with GiftRocker to create, exchange and redeem gift certificates, merchandise certificates, event admittances and promotions.   Partners through custom applications will perform all or some of these functions on behalf of their customers. Partners can also integrate GiftRocker wallet services into their custom apps.

When working with GiftRocker, the term “Offering” will come up often.   An offering is a template for a gift certificate, merchandise or an event.  In short, offerings represent what is for sale from the merchant or shop.  Shopkeepers will have zero to many offerings… although, if they had zero offerings, they wouldn’t have much of a shop!  An offering could be for a generic monetary gift certificate, admission to a show or a beer.

Offerings spawn certificates.  Whereas an offering is a template, a certificate is a instance of that template that has a value.  Certificates are typically paid for and always have owners.

A typical use case for GiftRocker services is as follows:

  • Customer gets into partner app (your app)
  • If partner is a shopkeeper, customer receives a set of offerings.
  • If partner is a 3rd party representing multiple shopkeepers, the customer will first find shopkeepers with something to sell using the Shops for Location service.  Alternatively, the partner app can keep a reference to Shops with goods to sell.  After selecting shop, customer receives a set of offerings.
  • Customer selects a specific offering, initiates a payment and receives good (the certificate).  The certificate can be gifted or kept by the customer.
  • Customer selects a specific offering, initiates a payment and receives good (the certificate).  The certificate can be gifted or kept by the customer.
  • Customer views owned certificates in partner app (your app).

Paying for certificates (the ones that require payment) through these services requires a credit card.  As a partner, your end users will be using these services to purchase goods at a merchant.   Since your end users will be presenting their credit cards to a smartphone rather than the merchant itself, these transactions are considered “card not present” or CNP.  This is similar to purchases made on the Internet.  The reason this is mentioned here is that CNP transactions require both the card number, CVV (number on back) and address of card owner.

From an ease of use perspective, the users of your app will probably not want to enter all required information when making a payment.  It is recommended that partners cache address information.   However, partners are required to adhere to the Payment Card Industry, PCI standards.  What this means, when trying to make life easy for your users, you can store name and address for convenience but do not store credit card information.

A future release of GiftRocker  will allow partners to allow their customers to store credit card information within GiftRocker’s service stack.  A reference will be given to the partner to associate to customers.  This will allow the partner to offer customers the convenience of holding credit cards in their virtual wallet.

Services are implemented using JSON (Javascript Object Notation).

Comments are closed.