iBorodum

The client had some specific requirements for how the app should work, both with the website and another app in use. Specifically, the Split Payment app had to be customized so that the payment for the borrowing service would be charged from the customers in advance, and a second payment for the actual products that were borrowed would be deferred and then cancelled right after the products are returned.

The original Split Payment app allows paying for the order in multiple shares. Customers can choose the number of payments and set the required amount of money. This wasn’t suitable for our client, because they needed only two payments to be applied with a fixed amount in each:

Service fee for the first payment is created by a third-party app. When customers order something from the store, this third-party app calculates the cost of a service fee and adds it to the main order as a separate product.

Also, the standard functionality of our Split Payment app implies that each deferred payment has a deadline, and when the deadline is about to expire, an invoice is sent to the customer with a reminder to pay for it. After the expiration date, the draft order that has been created in the Shopify admin panel becomes closed — it doesn’t track whether this draft order was paid or not. This did not work for our client, so we customized the app to keep draft orders open, even after the deadline had expired.

Another issue we needed to avoid was sending the customers invoices that were no longer needed. The third-party app was managing the return of products, and our app was dealing with payments and invoices. We needed to synchronize the work of the two apps, so the payment app wouldn’t send customers an invoice for the second payment if they had already returned the product after borrowing it. To do that, we customized the app and added the functionality which would track and cancel those unnecessary draft orders.

If a customer does not return the product after borrowing it, the full product cost is not charged from the account immediately — customers just receive an invoice with a reminder to pay if they’d like to keep the product. This way the business was at risk, so the way out was adding a service agreement before customers could complete the order.

This functionality wasn’t a customization, but the development of a completely new feature within the app. In the Split Payment app there is a pop-up which appears right before checkout and specifies the number of payments with the required sum.

We changed the apps’ functionality and added to this pop-up a service agreement checkbox — so customers sign an agreement with the store on service delivery upon ticking the box.

The client wanted the possibility to add discount codes during marketing campaigns, but this feature wasn’t available in the Split Payment app out-of-the-box.

We customized the pop-up and implemented the possibility to enter a discount code that would later be applied to their service fee and the subsequent payment.

Behind all this stands a rather complex functionality that allows us to bypass the restrictions connected with the Shopify draft order, and change the final price in accordance with the applied discount code.

Eliminating all reloads was technically impossible because of the Shopify restrictions, so we reconsidered the logic behind the app’s work and managed to get rid of some of them. And to let the customers know that the remaining reloads happen for a reason, we also added animation.
The end of the animation would show that all background updates had ended and the page is usable again.