Postilion VAS Integration

Value-Added Services (VAS) let a retailer sell prepaid electricity tokens, airtime, water, and bill payments at the till, alongside standard card and cash sales — the customer still pays however they normally would. VAS rides on the same Postilion/eSocket.POS payment infrastructure already deployed for card acquiring, so a retailer that already accepts card payments through Postilion can add VAS without a new integration footprint. Funding and settlement for VAS purchases run through Eclipse wallets, and the product itself — the token, airtime, or bill confirmation — is provisioned by eSolutions.

This section is for anyone who needs to understand how the VAS solution fits together: retail integration partners planning a till/POS integration, and anyone reconciling or supporting VAS purchases as they move through Postilion and Eclipse.

Architecture overview

Every till lane runs the retailer's POS application and eSocket.POS side by side on the same machine. eSocket.POS is the only component that ever leaves the store network, over a single outbound, encrypted connection to Postilion. Postilion settles the purchase by moving funds between Eclipse wallets, and the VAS itself is provisioned through eSolutions.

📘
No cardholder data in VAS traffic
VAS transactions carry no PAN, track data, or PIN, so they do not themselves extend PCI-DSS cardholder data environment (CDE) scope. Card PURCHASE transactions are a separate message type that shares the same outbound link and remain in PCI-DSS scope — the two coexist on the same encrypted channel.

What's in this section

Page	Purpose
Flow of Funds	How a VAS purchase and its reversal move money between the VAS reseller, Eclipse wallets, and eSolutions
VAS Developer Guide	Everything a till/POS integrator needs to build the REQUEST / PROCURE / REVERSE flow, parse responses, print receipts, and handle errors