Prepaid billing in Splynx

In version 1.2 of our system we have added feature of full prepaid billing. It’s used when ISP charges customer in advance and provide him access for certain period of time. When balance of the customer reaches set limit, he is disconnected. Each customer has a type of billing – “Recurring payments” and “Prepaid”.

To set up hard prepay we need to change the billing type of the customer to Prepaid.

type_of_billing

 

 

 

 

 

 

 

 

 

 

 

Then we define what is the value of customer’s balance when Splynx will block his access to internet. By default it is set to “0”, but it can be changed in configuration of each customer in the field “Minimal balance”.

minimal_ballance

 

 

 

 

 

 

 

 

 

 

 

 

After setting up type “Prepaid”, we need to add a payment to customer’s account. For example, 20 USD has been added.

payment

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The deposit of the customer changed to 20 USD.

deposit

 

 

 

 

 

 

 

 

 

 

 

 

 

Let’s add a service of 5 Mbps for 40 USD/month. Splynx calculates the daily rate of the plan and charges user every day. There are 30 days in October, so daily rate is 1,33 USD. Tomorrow balance of the customer will be changed from 40 USD to 38,66 USD and will continue decreasing every day according to his plan.

services

 

In this particular situation, when customer has 20$ as a deposit, he will get access for 15 days. Then he reaches “0” on his balance and Splynx will block him.
If we check the deposit of the customer the next day, it will be reduced based on the daily fee:

prepay_balance
 

 

 

 

 

 

 

 

 

 

 

 

 

Also one transaction has been added, which shows how much we charged. This transaction is updated every day and it shows the total amount of money that has been taken from customer’s deposit.

prepay_transaction

If “Make invoices (after to charge)” is enabled, Splynx will generate an invoice for consumed services  on a first day of the next month.

You can find how to setup blocking in Splynx in other article:
https://splynx.com/2666/blocking-of-non-paying-customers/

Description of prepaid billing engine is available on video below:

Cashdesk module

Cashdesk is a Splynx module for processing payments. Administrator can create Cashdesk users and provide them access to the module. User is not able to change and view any customer’s data except his name/company name, invoice numbers and actual balance. The Cashdesk can be used by accountants who doesn’t have to get access to Splynx but only to process the incoming payments. It can be also used by resellers. Reseller will only see his customers and will be able to enter payments to Splynx when he receives money from a customer.
The first step for Cashdesk activation is installation. It’s performed by two following commands in Linux CLI where Splynx is installed:

apt-get update
apt-get install splynx-cashdesk

To create a Cashdesk user it’s needed to create an administrator and define him permissions to Splynx access. He can have some permissions to access Splynx or he can get 0 permission level and access Cashdesk only:

cashdesk_admin
When the Cashdesk is installed, it’s available on “http://yoursplynxurl/cashdesk”.
The first screen is a login page:
cashdesk_login

Cashdesk user has logged, he can search customers based on customer’s name, login or number of invoice.

cashdesk_search

After entering the invoice number or customer name in search field, Cashdesk displays customer information with his balance and unpaid invoices.

cashdesk_user

The last step is to add the payment and write a comment.
When the payment has beed added, it appears in Splynx as a new transaction and also as a payment with comment, entered in Cashdesk.

payment

All payments of the user “casher” can be found in History section of Cashdesk.

cashdesk_history

The tutorial for Cashdesk you can find in the video below:

Contention in Splynx (aggregation of users)

Splynx provides the feature of contention or aggregation. This feature is used when ISP sells to the end users services with contention rate for example 1:5, 1:10 etc. Contention means that end user will share the bandwidth with other end users in his group.

Splynx operates with two types of contention: Per plan based and per router contention.

1. Plan based contention.
Let’s take a look on example.
We are selling to the end users plan 5 Mbps with contention rate 1:5. It means, that Splynx will setup the parent speed-limit of 5 Mbps and under this parent it will place 5 users with speed-limit of 5 Mbps each. What will happen in this situation: if line is free and one user starts to download/upload, he gets full 5 Mbps throughput. In case, when second user actively starts downloading, they will get 2,5 Mbps each. When all 5 users will simultaneously download with maximum speed, they will share the bandwidth.

It’s described in the image below:

Plan1

 

 

 

 

 

 

 

 

 

 

We can tune a bit sharing of speed with setting up “Limit-at” or guaranteed speed. If we place 1 Mbps to each user, then all users will always get at least 1 Mbps.

In that case all 5 users will simultaneously download with 1 Mbps speed. It’s shown on a second screenshot.

Plan2

 

 

 

 

 

 

 

 

 

 

What will happen in situation, when we will put 7 users on 1:5 contention plan ? Splynx will change the parent speed to 7 Mbps in this particular case, but will leave maximum speed of each user on 5 Mbps.

Plan4

 

 

 

 

 

 

 

 

 

 

 

 

 

If you are planning to deploy Plan-based contentions, use it on central routers to achieve high amounts of users in one tree. Compare two situations – 1:5 contention tree with 5 users and two of them are hard downloaders, it means that 3 other users will never get 5 Mbps speed, because they are all under one common parent of 5 Mbps.

If we place 20 users on this contention 1:5, then parent maximum speed will be set to 20 Mbps and then two or more high downloaders will not use the whole bandwidth.

Plan5

2. Router based contention.

Router based contention is used in this scenario:

Imagine that we have a wireless AP which is connected to backbone network with 30 Mbps speed. But we connected to that AP users with total possible bandwidth of 60 Mbps. What can happen in a peak time is that users will consume more traffic than can be sent through uplink. It means that wireless link can become overutilized and unstable. It’s shown in the picture below.

Topology-Router1

To prevent this situation, router based contention can be used. In Splynx each router has field “Sector/Speed limits”, where can be defined groups and administrator can put users under these groups. As a result we will achieve contention per router :

Router4

 

 

 

 

 

 

 

 

 

 

 

 

 

In a short video tutorial you can find how to configure Splynx and Plan based contention:

Configuration of Router based contention is shown on other video:

 

Blocking of non paying customers in Splynx

Splynx blocks non paying customers automatically. Also administrator can block the customer manually. When customer is put to Blocked or Inactive status, Splynx sends to router command to block him. If status is changed to Block – Splynx never cuts the service, but places the IP of end user to Address-list or give hime IP address from IP pool for blocked customers. Then administrator can create a rule on router for redirection of non-payers to a special page.

Splynx has 4 default blocking pages which are located at : http://yoursplynxurl:8101, http://yoursplynxurl:8102, http://yoursplynxurl:8103 and http://yoursplynxurl:8104

It’s a simple HTML file, which you can change via command line inside your splynx installation (SSH) at  /var/www/splynx/web/errors/ and folders 1,2,3,4 correspond to ports 8101, 8102, 8103 and 8104

Example of default blocking page is shown below :

2016-09-02 03.53.25 pm

Example of how the page can be customized :

2016-09-02 03.52.51 pm

There are 4 types of blocking scenarios :

1. Mikrotik API blocking
If you use Mikrotik based authentication – Hotspot, DHCP, Wireless or PPP, then as the first step, you should enable API blocking of users. It’s called “Disabled customers to Address-List” in Router API settings:

disabled

When customer is moved to status “Blocked”, his IP address is put to address list “SpLBL_blocked”. With setting up the rules for redirection, you can achieve that customer will see a special webpage with information why his access to the Internet was blocked.

2. Radius COA blocking
In Radius by default we also work with Addres-lists. Splynx uses names of address lists Reject_1, Reject_2, Reject_3 and Reject_4 for different type of errors. The names of address lists are configured under Config -> Networking -> Radius and also under field COA Block attributes:

2016-09-02 04.18.24 pm

3. Radius Session disconnection
The difference between Radius COA block and session blocking is that with COA session of customer is not disconnected, while in Session blocking his session is cut and user must reconnect his device.

The setting how to block user is defined in Config -> Networking -> Radius “Customer Block” and “FUP Block”:

2016-09-03 02.17.07 pm

4. Radius IP pool blocking
If customer gets IP from dynamic pool, or when NAS router is not a Mikrotik, Splynx gives to the blocked customer IP from Reject IP pools. By default these pools are 10.250.25x.0/24, but it can be changed in Config -> Networking -> Radius as shown on screenshot below:

2016-09-02 04.17.17 pm

If you use Mikrotik routers, there are 2 rules to redirect all TCP traffic to the blocking webpage and to cut all other traffic like Peer to peer connections (redirect them to router itself):

/ip firewall nat add action=dst-nat chain=dstnat protocol=tcp src-address-list=Reject_1 to-addresses=10.0.1.158 to-ports=8101
/ip firewall nat add action=redirect chain=dstnat protocol=!tcp src-address-list=Reject_1

All four methods of Splynx user blocking  you can find on our video tutorials:

Mikrotik API blocking of non payers

Radius COA blocking of non payers

Radius code disconnect (session reset)

Radius reject IP pool assignment