If the validation fails for InvoiceDirect and you want to send an InvoiceLink, you can do so. The InvoiceDirect would get the status:
Invalid. It would not be stored at our end, and therefore you can continue sending it as InvoiceLink
You can create 2 types of Invoice: InvoiceDirect and InvoiceLink.
The main difference is how Invoice is presented to the user - directly to the app or sent by link and then opened in the app by the user.
|As a Merchant do I ...?||InvoiceDirect||InvoiceLink|
|Do I want to manage Invoice delivery to the user?||
I just want to create an invoice and MobilePay should manage the rest.
I want to sent an invoice to my user, so the user can choose to pay it with MobilePay or with a different payment method.
|Do I want to send the invoice directly to the users app?||
I want Invoice to appear in users app instantly.
I want to send invoice as a link to the user by various channels: email, sms, merchant self-service site, etc.
|Do I know the mobilenumber, name and surname of the person, who will pay the Invoice?||Yes
I know users contact information like phone, name, surname.
I don't know users phone, name or surname, but I know other contact information like email to send the invoice to.
|Do I want to receive the payment exactly from the user i set in on the Invoice?||Yes
I want to receive the payment from exactly the same user i set on the Invoice
It doesn't matter who will pay for the Invoice, as long as it is paid on time.
The solution in short
- The merchant creates an invoice direct
- Do that through our API with relevant information, name and user phone number.
- Via link
- Do that by calling our API with relevant information without phone number.
- In return, you'll get a link that must be wrapped in a "Pay with MobilePay" button
- Present the "Pay with MobilePay button" to customer.
- User pays
- Pay now: just click and swipe
- Pay later: Preview the bill and schedule payment for later date.
You can tailor Invoice to various use cases...
- At merchant self-serve sites
- The customer has a log-in to merchant website
- Sent to the user (once you know who the user is etc)
- It is similar to a normal E-commerce flow
- In store and/or phone
- Staff creates customer in their own system and chooses MobilePay
- MobilePay website opens and asks for the mobilenumber
- You ask the customer for the mobilenumber
- The customer gets a notification in MP and approves
End user benefits
- User can choose to pay now, on due date or on a user selected due date
- Pay in time
- Don't miss a bill
- Manage and find your paid bills, payment and bill are connected - also after the payment
- Pay your bill with a "click and swipe"
- ERP integrated using open API's
- Flexible API integration
- fits the needs and meets many user scenarios
- Merchant don't need to know the mobile number
- Easier billing
- Payment on time
- merchant uses less time on reminders
Review our documentation on Github* using the link below. here you find extended technical documentation
* GitHub is an external site which is not owned by MobilePay. MobilePay is not responsible for technical errors or downtime on GitHub.