Scenario Other Factors Solution Result
Android/iOS POS developer needs payment solution for many merchant customers Merchant bank relationships necessitate multiple gateway interfaces, while developer wishes to remain gateway-neutral IntentToPay presents a single payment interface, with connectivity to virtually any gateway, processor, or payment switch POS product can be marketed to any merchant, regardless of merchant-bank relationship; developer free to focus on core product
POS Developer or ISO needs asset management controls Customers demanding more tools from developer to track device placement and manage migrations IntentToPay back-end provides intuitive dashboards, controls and reporting, so developers and ISOs can self-manage their portfolios Developers and ISOs benefit from IntentToPay asset management tools that simplify hardware tracking and migrations
Merchant wants to self-manage services and profiles on their own devices Merchant interested in alternative payment channels, as well as asset management across multiple locations, each with multiple devices IntentToPay back-end provides intuitive dashboards and reporting, so merchants can self-manage their portfolios Intuitive merchant dashboard provides device status, chain-of-custody, services status, device health, activity history, and other controls
ISO needs to migrate large merchant portfolio ISO is changing sponsorship contract, requiring migration to new FrontEnds for thousands of merchants IntentToPay asset management tools allow the ISO to drive migration, based on various filters, controls and methods Merchants converted with no touch, and no interruption of authorization services
Merchant needs multi-routing options for authorization Wishes to add additional payment routes for gift card, international and Bitcoin transactions IntentToPay easily supports multiple authorization routes, with dynamic routing profiles Authorizations routed based on default route; transaction pointer; or configurable rules. Solves for acquirer-independant Durbin debit routing requirements, and On Us routing
Android/iOS POS developer needs to eliminate impact of breach and minimize PCI compliance for his merchants Developer does not have resources to develop interface to encrypting reader, required to eliminate submission of in-the-clear PANs IntentToPay screens for, and rejects any inbound data containing in-the-clear card (PAN) data, keeping the POS software outside the regimen of PCI - it cannot “store, process, or transmit PAN data” Benefits are threefold: any breach of the POS software finds no sensitive card data; PCI validation for the merchant is simplified, through SAQ and/or QSA; POS developer relieved of effort code to encrypting dongle or reader

Powered by ChronoConnectivity - ChronoEngine.com