Payment Service: Price Check

Adobe AIR Development

Not every app that makes use of the payment service will want or need to display a price to users in the actual app interface. Many apps rely on the payment confirmation window to retrieve the price of the digital good from the BlackBerry World server then display this information to the end user, which is a perfectly acceptable option. If you are creating an application where you have a long list of digital goods and would like to display the prices for these then I have a nice little optimization you are going to be interested in!

paymentservice1Picture by MTSOFan

Today all calls to the Payment Service must be done sequentially and every call you make to retrieve the price of a digital good follows this pattern:


The key issue with the above process is the inherent latency experienced if trying to retrieve the price of many digital goods at once. Wouldn’t it be great if the Payment Service on the device would just grab all those prices at once and cache them all rather than requiring repeated network calls? Of course it would, and the dev team behind the Payment Service has added a really simple feature to do just that! All that is needed is one minor code (if you’d even call it that) change.

Here’s a quick example using the Cascades PaymentManager calls that shows how a price is retrieved without caching:

m_paymentManager->requestPrice(NULL, digitalGoodSKU);

And with caching enabled:

m_paymentManager->requestPrice(NULL, CACHE:digitalGoodSKU);

As you can see the only change we made was to prepend the SKU with “CACHE:”, that’s all, everything else is handled for you by the system. Similar logic will work across all languages on BlackBerry 10 (HTML5 WebWorks, Native, AIR). Let’s take a look at what the above “code” change has achieved for us in our app:


Now the Payment Server is responding to the Payment Service with the entire list of SKU-price pairs. The Payment Service caches these prices locally then responds back to the client app with just the price requested. All subsequent calls to the SKU price requests will have the values pulled from the Payment Service cache and returned to your application almost instantly:


You just need to make sure that you keep all SKUs prepended with “CACHE:” to make use of the price caching and the Payment Service will handle the rest. The prices will get cached locally for 30 minutes after which they are purged. One other thing to note is that this caching mechanism is not compatible with the Content ID, only the SKU, so if your app is passing the Content ID today you would need to change it over to use the SKU instead.

This feature is very helpful if you know you will be retrieving a bulk of SKU prices all at once, but at the same time this can add some overhead to the call if you only need one price, so be wise in your implementation.

About garett

Garett is a member of the Developer Relations team and has been with BlackBerry since 2008. He specializes in app monetization (Payment, Advertising, Analytics SDKs) and Push development. He is one of the individuals involved with the forums (gbeukeboom), Issue Tracker and can be found tweeting from @BlackBerryDev with the ^GB signature.

Join the conversation

Show comments Hide comments
+ -
  • 黑莓精英每周沟通 | 中国黑莓开发网

    […] 了解缓存付费服务价格的方法, 可以查看开发者站点的文章,只需要添加一点代码就能实现了。:) […]

  • Cash Rules Everything Around Me: Making Money as a Developer | BlackBerry Developer Blog

    […] teammate Garrett wrote a great post, “Payment Service: Price Check,” in which he takes a much closer look at the Payment Service itself. It’s worth checking out […]

  • [成功案例]现金主宰着周遭的一切:作为开发者如何赚到钱? | 中国黑莓开发网

    […] 我的队友加勒特写了一个伟大的职位,“ 缴费服务:价格入住 “,在其中他需要更仔细看看支付服务本身。 这是值得一试,如果你想进入应用内购买。 […]

blog comments powered by Disqus