Mangopay adaptive plugin is completely out of date

  • Posts: 128
  • Thank you received: 2
7 years 5 months ago #253596

-- HikaShop version -- : 2.6.4
-- HikaMarket version -- : 1.7.2
-- Joomla version -- : 3.6.4
-- PHP version -- : 5.6

Hi Jerome and team,

Mangopay is an excellent Payment Gateway for marketplaces where adaptive payments are required and hence it goes together very well with your HikaMarket-Multivendor product. You know that already and that's why you developed these plugins ( Hikashop Payment and Hikamarket ). It is especially cool the front end HikaMarket implementation where each vendor can manage their Mangopay wallet and account directly from the HikaMarket front end.

However I understand you developed these plugins some time ago and the Mangopay platform has moved on since then. Even though your code works well, it is NOT implementing correctly the concepts that Mangopay proposes today.

It is important you understand that Mangopay is a financial institution and has a set of legal obligations related to their license as an electronic money issuer, which are necessary in order to fight fraud, money laundering and financing of terrorism. So the information our application (Joomla+Hikashop) provides per transaction needs to be accurate.

For example, according to Mangopay documentation docs.mangopay.com/guide/kyc a Natural User who makes a Payin (i.e. a user who makes a purchase from a vendor in our online marketplace ) needs to provide this info:

Email - Email
First name - FirstName
Last name - LastName
Country of Residence - CountryOfResidence
Birthday - Birthday
Nationality – Nationality

When looking at how the Hikashop Payment plugin creates the user in Mangopay for the buyer we see:

protected function createUser(&$order) {
		if(!$this->getAPI())
			return false;

		$billing_address = $order->cart->billing_address;

		$user = new MangoPay\UserNatural();
		$user->FirstName = substr($billing_address->address_firstname, 0, 99);
		$user->LastName = substr($billing_address->address_lastname, 0, 99);
		$user->Email = $order->user->user_email;
		$user->Address = substr($billing_address->address_street . ' ' . $billing_address->address_city, 0, 254);
		$user->CountryOfResidence = $billing_address->address_country->zone_code_2;
		$user->tag = 'hkId:' . (!empty($order->order_user_id) ? $order->order_user_id : @$order->user->user_id);

		$user->Nationality = $billing_address->address_country->zone_code_2;
		$user->Birthday = time();

This code is assuming that both the Nationality and the Country of Residence of the buyer are the same and takes it from the Country in the Billing Address. And the nationality of the buyer in many cases will be different from the country he/she lives.

Another problem is the Birthday. Your code is just using the day that the purchase is being made which has nothing to do with the buyer's birthday.

Recording wrong information in Mangopay puts us as a Marketplace and our Vendors in a very weak position if the customer files a dispute for the payment. And what is worse, we would NOT be complying with Mangopay terms and conditions.

Another big problem I see is that you guys seem to be using version 1.6 of the SDK which supports MangoPay API v2 but does NOT support the current API v2.01. As per docs.mangopay.com/blog/new-api-version-v201 , the API v2.01 is available from July 2015 and it is mandatory from 15th September 2015 to be able to do PayOuts to bank accounts in the United States or Canada. So that means the current implementation CANNOT support vendors who live in the US or Canada - in my business case the majority of vendors are in the US.

Another huge limitation is the fact that your code assumes that ALL vendors are registered as Legal Entities ( Sole Trader, Business or Organization ):
protected function createVendor(&$vendor) {
		if(empty($this->api))
			$this->getAPI();

		$user = new MangoPay\UserLegal();
		$user->Name = $vendor->vendor_name;
		$user->LegalPersonType = 'BUSINESS';
		$user->Email = $vendor->vendor_email;
		$user->HeadquartersAddress = substr($vendor->vendor_address_street . ' ' . $vendor->vendor_address_city, 0, 254);
		$user->tag = 'hkVendorId:'.$vendor->vendor_id;


An online market place is normally used by people who are just starting to sell online and need to be able to do it as a physical person (i.e. Mangopay Natural Person). Once they are big enough to register as a Business probably they will build their own online shop and will not need to use a marketplace any more. In my business case 80% of the vendors are not registered as a Legal Entity hence I cannot support them with the current implementation of the Mangopay plugins.

Please do not take this post as a negative critic. I really like Hikashop/HikaMarket and I think it makes a great combination with Mangopay. I'm just highlighting with clear examples why this combined solution does not work in practice today and why we need a new version of the Mangopay plugins which can support today's business cases.

It is a great opportunity for the Hikashop/HikaMarket team to shine again. Are you up for the challenge? Could you provide a time estimation about when a new version could be ready?

Many thanks!

Please Log in or Create an account to join the conversation.

  • Posts: 25994
  • Thank you received: 4004
  • MODERATOR
7 years 5 months ago #253621

Hi,

MangoPay is a very interesting payment system but the system had some missing parts when we made the first implementation of our plugin (in February 2015).
Yes, the way than the "sellers" are managed is now different in the new API ; they added the "Sole Trader" and a "Natural user" can also be a seller.

I wrote a big email in March 2015 in order to list problematic points in the API/Documentation ; like the birthday in timestamp format, the way than credit card are handled, the management of the addresses in a user regarding the billing address ; the absence of documentation of the data in the user object regarding the "KYC" ; the way to handle KYC documents for customer during the checkout or to be able to determine if the user reached a limitation or not ...
I was happy to see some improvements even if they had too much modifications in their SDK in short periods ; it does not allow a software like HikaShop/HikaMarket to provide a stable support if the SDK is not stable enough. That's the main reason why we did not migrate during summer 2015.

The plugin proposes an interface for the vendors so they can manage their account, configure the legal name, upload some documents, etc.
In the first design we made, the plugin should come with an interface for the customer to configure the details like his birthday, etc.

That interface in the checkout was design to use the checkout system provided by HikaShop 3 ; because that plugin was part of a big development project, with a financial support.
Unfortunately, the client who started the MangoPay and HikaShop 3 project had issues and broke his engagement in the contract we signed. So, the development of HikaShop 3 and the MangoPay plugin stopped due to several months of work unpaid.

It took us a long time to complete the HikaShop 3 project on our own which has been finally merge into HikaShop and we recently released an Alpha package (and the Beta is on its way).
We are still focus on that development and the MangoPay plugin will be able to continue his evolution when the required feature will be ready for everyone. We lost too much time with that sad story and I'll be happy to move on.

If you take a look at HikaShop 3 you will see that we made ourselves big challenges.
Updating the MangoPay plugin and implementing the new features is something possible but I can't provide any schedule for the moment.
But once the new major version of HikaShop will be release, it will be possible to see how that development can be done.

Regards,


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.

Please Log in or Create an account to join the conversation.

Moderators: Obsidev
Time to create page: 0.055 seconds
Powered by Kunena Forum