HIKASHOP ESSENTIAL 60€The basic version. With the main features for a little shop.
HIKAMARKETAdd-on Create a multivendor platform. Enable many vendors on your website.
HIKASERIALAdd-on Sale e-tickets, vouchers, gift certificates, serial numbers and more!
MARKETPLACEPlugins, modules and other kinds of integrations for HikaShop
-- HikaShop version -- : 3.0.1
-- HikaMarket version -- : 1.7.3
-- Joomla version -- : 3.7.1
-- PHP version -- : 5.6
Hi there,
I find quite difficult to understand refunds when using HikaMarket multi-vendor and MangoPay Payment plugin. In particular how to refund vendor suborders.
I’ll explain how I am doing it:
Step 1. The customer places the order and pays via Mangopay
--
Please Log in or Create an account to join the conversation.
Hello,
Sorry but your message have a lot of questions and it's very very (very !) difficult to follow and answer to them.
Please make real points in your next messages or several threads for different questions.
Once a sub order is paid, his "vendor order total" do not change ; because it already been paid.
You can change his order status it won't change the fact that the sub order has been paid for the "vendor order total" it contains.
But you can find other sub orders for the vendor adjustments, when you make the sum of all of them, you got the final vendor order total for his current "status".
These adjustments are not real vendor sub orders ; so they do not have any order number ; because they are not orders (no product, etc) but just vendor price adjustments.
Afterwards, the HikaShop order export is related to HikaShop and extract the raw data from the database ; it does not export the "adjustments" because they are not visible in the HikaShop interface.
With HikaMarket 1.8 I want to change a bit how the sub-orders act and how the vendor order total is stored. I want to avoid the creation of these adjustments and store that data in an HikaMarket table.
Regards,
Please Log in or Create an account to join the conversation.
OK, if you have trouble understanding what I mean let's see if I can understand you:
Can you please explain step by step how are we supposed to do a refund for a Vendor suborder that has been paid via MangoPay? Including what happens with the adjustments and how we are supposed to deal with them
Thank you
Please Log in or Create an account to join the conversation.
Hello,
There is no current support of automatic refund in the MangoPay plugin.
But there is an option in the plugin (in the Joomla part of it) named "Order statuses for wallet transfer".
It allows you to specify for which order status the customer wallet money will be transferred to the vendor wallets.
Once the transfert is made, the order is marked as paid and you logically should not set the order as refund afterwards.
Now, I can see to add features in the plugin to perform a "rollback" transfert if the order pass as "refund" and when the vendors have been already paid ; but I admit that I'm not really fan of it regarding all possible side effects (like, if the vendor already get the money to his bank account).
It is also possible to handle the refund using the MangoPay API but in a way, I would prefer to integrate with an HikaShop refund system (the idea is to have a "refund" button when you edit the order in the backend, so you are really sure that it's not a order status modification mistake).
Regards,
Please Log in or Create an account to join the conversation.
Hi Jerome,
Thank you for your good ideas for the future but this is NOT what I’m asking.
I would like to understand what is the process to do a refund NOW, with HikaMarket 1.7.3.
I understand there are some manual steps and that we cannot handle refunds now with the Mangopay API. That’s OK, I can go to the MangoPay dashboard and execute an action manually.
I just would like to know what actions I need to perform and in which order when a Vendor contacts me and tells me that his customer has requested a refund.
Surely before you do the coding, you need to think about a business logic which is what you are trying to accomplish with your coding. So that is what I would like to understand, how you thought the software should be used when you did the coding. Please!
I would like to see something like for example (this is just an example, I’m sure it is not right):
-Step 1: move the Vendor suborder to refunded
- As a consequence of Step 1 an order adjustment is created on the Parent order.
-Step 2: In the Vendors section of the backend, go to the Vendor in question and then click Pay. Select the order None and click pay.
- As a consequence of step 3 a new order is created as which represents the money to be returned by the Vendor to the store.
- Step 4: Once the money from the Vendor is received by the Store change this new order to confirmed.
- As a consequence of step 4 Vendor is notified of payment received for the settlement order
- Step 5: go to mangopay dashboard an return money to customer
- Step 6: notify customer
-Step 7: bla bla bla
This is just an example of the type of answer I am expecting from you and what I would consider good support. Please, please (please!)
Please Log in or Create an account to join the conversation.
Hello,
The refund process with MangoPay is the same refund process than with any other payment system using HikaShop ; you need to do it manually in the payment platform interface.
I wrote you to configure the plugin MangoPay in order to avoid the transfer of money to the vendors "too soon", so you do not have to perform tasks like "transfert the money from the vendor wallets to the customer wallet" ; which can be something complicated to do in their interface.But there is an option in the plugin (in the Joomla part of it) named "Order statuses for wallet transfer".
It allows you to specify for which order status the customer wallet money will be transferred to the vendor wallets.
Once the transfert is made, the order is marked as paid and you logically should not set the order as refund afterwards.
Please Log in or Create an account to join the conversation.
Hi Jerome,
Thank you for your patience, finally I feel we are on the same page. I appreciate your support.
The way I control that the Vendor does not take the money too soon is by making the “payout Waiting duration” in the Joomla Payment Plugin 14 days. “Order Status for Wallet transfer” I leave it blank so it follows the Hikashop configuration as per your recommendation in another post. This setup works well because the Vendor sees his money in his wallet as soon as the order is confirmed, but he cannot withdraw his money until 2 weeks later.
So, if the customer requests a refund 7 days after paying the order that money is still in the Vendor Wallet. So from the MangoPay dashboard I can transfer back to the user wallet and then trigger a refund to his credit card. It is manual but it works.
So lets test the process you suggest:
- Step 1: Return the money from the Vendor wallet to the customer using the MangoPay interface.
- Step 2: Set the Parent Order as “Refunded” and select notify customer.
Consequences of Step 2:
2.1 The Vendor Suborder does NOT change to refunded, stays as confirmed
2.2 Now when the Vendor looks the order from the Vendor Control Panel he sees Vendor Total = 0 Euros (X Euros unpaid to Store) SCREENSHOT_1→ this is NOT correct because the money has been taken in Step 1
-Step 3: Set the Vendor “None” Payment as paid (shows with status refunded)
Consequences of Step 3:
3.1 New Order created to the admin account of the Vendor. Status “Created”. → this is NOT correct because the Vendor has paid this on Step 1
3.2 The Vendor suborder stays as “Confirmed”. Still it does NOT change to refunded
3.3 Now when the Vendor looks the order from the Vendor Control Panel he sees Vendor Total = 0 Euros and the orange tick saying (vendor has been paid for this order) SCREENSHOT_2 → Previous problem (2.2) is now fixed.
-Step 4: Set the new order created (3.1) as confirmed → Previous problem (3.1) is now fixed
BIG PROBLEM OF THIS PROCESS:
- The Vendor suborder stays as CONFIRMED and although the suborder view in the Vendor control panel shows Vendor Total = 0 Euros if the Vendor does a CSV of his suborders he sees this order as CONFIRMED and order_vendor_price = X Euros SCREENSHOT_3 → vendor will think he is missing money
ANOTHER PROBLEM:
- When the adjustment is marked as paid (Step 3), why is the new order created (3.1) to the admin user of the Vendor Account? The problem is that the CSV export for Vendor suborders does not include this order because it is not linked to the Vendor Account, so it becomes very confusing for the Vendor
ANOTHER PROBLEM:
- The new order created in 3.1 does NOT say it has been created because of an adjustment to order XYZ SCREENSHOT_4. There is no reference to the refunded order that triggered this adjustment.
Please Log in or Create an account to join the conversation.
Hello,
I'm sorry but I'm not following you for your workflow ; I do not understand what you're talking about.
1 - Oh yes, in HikaMarket 1.7 a paid order cannot be modified at all and the order status is not changed..
That's something I changed in HikaMarket 1.8 but with all the remaining tests I have to stabilize the new organisation (and the work I have for HikaSerial), I'm not able to release it yet.
Right now, the best would be to display the "current" order status from the "vendor adjustments".
In the hikamarket ordermarket/view.html.php file you will find the line
$order->refunds = $db->loadObjectList(); $order->refunds = $db->loadObjectList();
foreach($order->refunds as $refund) {
if($refund->order_vendor_paid == 0)
$order->current_order_status = $refund->order_status;
} if(!isset($this->edit) || $this->edit !== true ) {
?><span><?php echo hikamarket::orderStatus($this->order->order_status); ?></span><?php
} else {
$extra = 'onchange="window.orderMgr.status_changed(this);"';
echo $this->order_status->display('data[order][order_status]', $this->order->order_status, $extra);
} $order_status = isset($this->order->current_order_status) ? $this->order->current_order_status : $this->order->order_status;
if(!isset($this->edit) || $this->edit !== true ) {
?><span><?php echo hikamarket::orderStatus($order_status); ?></span><?php
} else {
$extra = 'onchange="window.orderMgr.status_changed(this);"';
echo $this->order_status->display('data[order][order_status]', $order_status, $extra);
}Please Log in or Create an account to join the conversation.
Hi Jerome,
ordermarket/show_block_general view, does NOT have the lines you suggest to replace. Please clarify the second file that needs to be updated in your suggested in point 1
Thanks
Please Log in or Create an account to join the conversation.
Hello,
It's the view show_general.
Afterwards, some modifications might be also needed in other "ordermarket" view to display the "current_order_status" instead of the "order_status", like in the views "show" and "status".
Regards,
Please Log in or Create an account to join the conversation.
