DropPay Shop API enables your application to implement services for a merchant who wants to get paid when selling product or services.
Your shop is what DropPay calls a Store and shows a name that DropPay calls Brand.
You should use POS API to collect payments and DropPay is flexible enough to make you accomplish with quite all the cases you're going to front with:
- one shot payments
- deferred payments
- recurring payments
- payment with preliminary money booking
and those mechanics can be available on different schemes like DropPay itself or credit schemes or debit schemes too.
What's a DropPay Merchant ?
We refer to a DropPay Merchant when a DropPay User is a Business Account Owner who have at least a Brand, and a Store for that Brand available for that Account. When you subscribe for a Business Account, DropPay sets the first Brand and Store by default. The default Brand coincides with the Account Owner Legal Name, and the Store supposed to be at his company address (headquarter or main site)
In DropPay Brands are actually what they literally mean and they are described by the following properties:
- Name: the brand name ;
- Logo: the URL of a useful logo image;
- Description: the brand descrition or payoff ;
- Business Categories: a list of product categories the Brand is legally authorized to offer and sell ;
A Brand uses a DropPay Business Account as payable account.
If your Application is about to work on top of DropPay POS API for one or more Stores of a Brand, it must have been Connected to every account reffered to the Brand the POS is enabled to. See also Connection for further details.
Brand API are detailed at Brand API page.
Brands inform payer about your company, Stores inform you where your company are selling a product or a service.
Store can be
- REAL : if they are placed at a real address and located also by longitude and latitude (i.e. a shop or a fixed advertising display);
- VIRTUAL: if they are places anywhere has not a real address (a website, an app, a magazine, a newspaper, and so on)
Customers get to stores to buy merchant's products and services, and merchant enable Point Of Sale devices (POS Devices) in the Stores to make their customers pay.
Store API are detailed at Store API page.
In DropPay API lexicon a POS is a sort of port that enables your application to engage a consumer in a payment.
A payment is procedure formerly made by two tasks:
- Authorisation: by which a merchant ask his customer to accept a way to pay for a purchased service or good; the merchant configures the payment proposal in terms of amount, recurring charges, user's approval protocol and limitations and all the subsequent Charges will be compliant with Authorisation user's approved settings;
- Charge: by which a merchant effectively takes money from the customer's account accordingly with Authorisation's settings.
That payment can be performed with a DropPay account and mobile app, or with a payment card (both credit and debit), with a SEPA SCT. All depends on POS Virtual Device attached to POS itself.
Every DropPay POS entity has a virtual device attached to and the POS Virtual Device implement the business logic fo payment process.
Different Virtual Devices have different behaviour enabling different sets of Authorisation's features and payment schemes.
They influence the Authorisation protocol too: for example with the DropPay or Static POS Virtual Device DropPay payer must be engaged in a two factor authentication in order to get the POS Authorisation granted. That's is not the case when the Virtual Device is of Acquirer type that grants the Authorisation at committing time because the assertion that user has already granted the scheme (i.e. credit Mastercard) elsewhere is considered valid.
POS isntances and settings are always visible in DropPay Secure Web Application.
Available POS Device are:
- DropPay - merchant applications consuming DropPay POS API on behalf of a merchant; these devices operates directly over DropPay POS API (Payment Scheme available: DropPay);
- Static - a single persistent customer engagement code you can create and manage. Once it's created it can be printed as a QR code or shared as a deeplink. Whenever a DropPay user import it in his DropPay mobile application a payment flow is execute on merchant behalf (Payment Scheme: DropPay);
- Sepa SCT - this device lets a merchant define a regular expression that traps a Sepa Credit Transfer incoming in his Brand's payable Account, considering it as a payment and taking advantage from all the other Shop API features and tools (Payment Scheme: SEPA SCT);
- DropPOS Checkout - this device is actually invisible to your application as long as you won't ever consume its API directly. DropPOS is a DropPay service built on top of DropPay API that publish its own API. It is self configured by merchant through the Developer Secure Area and allows a developer not to fully implement the DropPay Security Model but rather building a sort of light integration with a set of APIs strictly limited to the DropPOS Checkout's services. Get to POS Checkout for further details.
- Acquirer - this device let you develop solutions where the POS Device can be real or virtual and is not provided by DropPay (i.e DropPOS) but it is configured to exchange the payment from the customer's card scheme to A-Tono Payment Institute as acquirer (Payment Schemes: EMV, PagoBancomat, AMEX).
Get to POS API to get in deep.