Business cases

Integrating with PayLane systems allows you to implement a solution that will fit your business characteristics and even increase your income. You can even design your very own model and use our API to accept payments in a manner that suits you best. Here are a few examples of popular payment mechanism – perhaps one of them is what your need (or will inspire you somehow).

“Single sale” – the regular way

This is actually the most common way of purchasing goods online. Each and every transaction is initiated by a customer, and so is the payment.
Single sale

Single sale

Make it better

Regular shopping is quite all right, but it’s often a bit enhanced. For example, online shops create accounts for their customers. This way when a customer returns, they don’t have to enter their delivery address again – it’s already saved there.

But why not do the same with payment information? Of course that’s a lot more sensitive data. However, if you don’t want to go through all the security issues, PayLane can store card data for you (and it’s free!). You can just operate with specific ID numbers that will correspond with records in our databases, but there will be no actual data on your side, hence no need to create additional security layers.

Think about it this way – you have the customer’s address saved on your servers and you have access to card data stored on our servers. That’s all you need to process a payment and it’s up to you how the payment will be initiated by your customer. Design the model that fits your business best. Owing to this feature, you can upgrade or downgrade your SaaS, you can make your customers come back to you more often – they can just log in once and their data will be remembered, so they wouldn`t have to fill in the long and boring payment forms.

Recurring payments

Recurring payments are a solution commonly used with all kinds of subscriptions. It goes along great with magazines, online services (monthly/annual fees for pro accounts) and so on.

Initiated by the first sale

A customer must provide their card data and allow you to collect money from their account. This is often done within the first sale – every next payment is done automatically and refers to the first sale. This way the first purchase is a kind of key that gives you access to the customer’s card.
Recurring based on first sale

Recurring based on first sale

So the common path here is that a customer buys something for the first time, e.g. first number of an e-zine or first month of a pro account in you web service. That’s the first sale that will allow you to collect money automatically for next issues/months.

Initiated by card authorization

Sometimes you don’t want to collect money right away and that’s why there’s an alternative to the solution mentioned above. You don’t have to actually process the payment from the first sale to be able to collect money automatically. All you need is an authorization of the customer’s card. Of course the card data must still be provided, so in many cases it may seem not different at all (well, except for the fact, that no money is actually collected). But there are certain models that make such solutions quite reasonable. Think of it as of paid access to some materials or subscriptions for daily/weekly magazines. You give a week or two to look around, a test trial. If a customer does not resign until then, you start charging them. What’s more, if you offer multiple subscriptions like this and you already have the customer’s information. The customer chooses and gets a free trial; if they don’t resign, they start paying without the necessity of logging in or providing any data once more.
Recurring based on authorization

Recurring based on authorization