Library OpenApi Overview About these APIs Architecture Authentication Error Responses Locating a Server Sessions Design Guides Guides and Hints Examples Pricing for Websites Accepting Vouchers PreAuth Payment Replication Common Apis The most used APIs Create New Sale Payment Completion Multiple Locations Delivery Addresses Customers Locations Products Staff WebHooks eCommerce Apis These APIs are often used with eCommerce website integrations Get Pricing Card Inquiry Report & Analysis Grouped or analysed report data. Typically used to build reports and dashboards Today Login Access Pinboard ReportRequest Advanced Information More indepth information Caller Handling HTTP Protocol Bulk Data Downloads Document Uploading RetailConfig Under Development Details of APIs that will be available shortly. Documentation provided is for early adopters Get Receipt

Design Guide: Pricing for Websites

A simple website will interface to the retailers instore management systems and extract products and pricing information. This works well initially and everything works well. In store though, retailers often implement quite advanced pricing rules and want the website to reflect these same pricing rules.

Reproduce Store Pricing on Website

The problem around pricing is simply the complexity of the different options:

  • Products start with a retail price for each item. This is the ticket price observed by customers in the shop
  • This single price per product may be extended by having multiple prices against each product, called pricebands. A priceband is often selected based on the customer. For example, some retailers create a "Trade Price" priceband which is granted to trade customers.
  • Spot pricing rules might be created handle specific pricing exceptions. These are called "Pricemaps" in Fieldpine. For example, a pricemap might be created to allow a single customer A, buying item B in store C, during the month of July to pay only $z

The above pricing is relatively simple to implement with a products table

ProductTicket PricePriceband
Trade Price
Priceband
SPCA members
Dog Food 10kg Bag$14.95$11.40$12.16
Cat Food 500gm tin$2.95$2.06$1.97

And also a pricemaps table for exceptions

ProductCustomerDatePrice
Dog Food 10kg BagBobJuly$9.88
Dog Food 10kg BagSues Kennel and BoardingJuly to Sept$9.14

Now lets throw some discounts into the mix. Consider a 10% off coupon for dog food. Who does this apply too, Normal retail (ticket price)? Trade Price? SPCA? What about Bob and Sues Kennel - are these special prices entitled another 10% discount or is this the final price? While this can be done with flags and listing the exceptions, it is not uncommon to have 500,000 pricemap entries., although only a small fraction of them will be needed for a single sale.

When kits/combo pricing is used, pricing becomes dependent not only on the current item in isolation, but also the combination of items. Fieldpine has a wide range of different kits/combos available, which means that implementing them is difficult to reproduce. Some examples of kits

  • Buy an X and a Y for $z. This is the classic combo everyone thinks off
  • Buy an X, and get either and A or a B for 20% off.
  • Spend $100 on brand Y and get $10 off, spend $200 and get $50 off.

Kits are not represented as a simple table like other pricing methods. Rather each kit is defined as a descriptive set of instructions that are interpreted at sale time. This provides a high degree of flexibilty, but the code is more complex.

Pricing API

An alternative approach to trying to implement pricing is to call the pricing API while the sale is being created. This offloads all pricing to Fieldpine and offers the best alignment with instore pricing. The downside is that you need to call an external API and interface into your shopping cart.

  1. Sale is created and first item added
  2. A "sale object" packet is created and sent to the OpenApi to price the sale.
  3. This API returns the "sale object" with pricing, potential layout changes and other details
  4. Your code updates the shopping cart with this pricing
  5. Steps 2...5 are repeated as items are added and removed, or as other sale relevant factors are discovered, known customer, has a voucher, etc

Summary - Which to choose?

If your site is "simple" and the retailer only ever wants static pricing, implement pricing the classic expected way.

If you need to fully mirror instore pricing for Omni-channel selling, use the pricing API

If you are not sure, thinks about the following

 Code your own PricingPricing API
Range of Pricing Methods Limited to those you implement Extensive
Easy to implement Yes, for simple pricing. No for complex pricing Depends on shopping cart integration options
Development Cost Initial, and ongoing as new pricing methods required Initial only
Ongoing Cost None Usage charged