I'm using VM 2.0.6 and Joomla 2.5 and the Multisafepay payment gateway.
Whenever a user puts a product in his cart, and clicks on checkout, the user is send to another page completely (Multisafepay's website, so not VM anymore) where he can select his desired payment option - same thing as paypal for example. But, at that time, Virtuemart is already sending an e-mail to the user confirming his order. That e-mail is saying: Thank you for your order blabla, the status of your order is blank..
So, VM is already sending an e-mail before the user payed.
Does anybode relate to this or knows an answer?
VM 2.0.6 is working like this :
when the order is placed that means any one of the shipping and payment method is selected.
and cart have valid data it will create the order and send an email to the user that mentioned
an order has been placed.
You can change
the sending mail section if you need.
One function name with notifyemail (iam not sure the name but it start with notify) in the path:
administrator/components/com_virtuemart/models/orders.php
you can check all your required things like shipping /payment methods are selected before calling this function.
the function should be initiate from cart.php controller in front end.
You can change the point where an invoice copy is sent to the customer in the Store Configuration. Look for Configuration > check out > Default Order Status to send an invoice and make sure you have the Confirmed status chosen.
Related
I've never used PayPal before, it's not really popular here, and I'm confused by how the order and payment works. Can anyone explain it to me? I've read the documentation and I'm still confused.
To complete payer approval, use the approve link to redirect the
payer. The API caller has 3 hours (default setting, this which can be
changed by your account manager to 24/48/72 hours to accommodate your
use case) from the time the order is created, to redirect your payer.
Once redirected, the API caller has 3 hours for the payer to approve
the order and either authorize or capture the order.
I have created a working PHP curl call for this API in sandbox env according to the sample
https://developer.paypal.com/docs/api/orders/v2/#orders_create
The APIs I created before work like this:
Send a request to 3rd party payment
Get a response containing a checkout link
Redirect customer to link
Customer complete payment
3rd party send a request containing order and payment detail to a file/path on my server
My server receives the request and updates the order status/payment in my database
3rd party redirect the customer to my webpage
With PayPal, what I got so far is:
Send request containing order detail to /v2/checkout/orders
Get a response containing various links
Redirect my customer to the rel:approve checkout link
Log in to my sandbox customer account and pay using PayPal balance, click Continue
A popup message is shown: We're sending you back to xxx's Test Store to complete this purchase
The popup message is closed and I'm still at the same payment page with the Continue button as seen in the image
Send request containing order detail to /v2/checkout/orders
Get a response containing links
Redirect my customer to approve link
Step (3) is an old integration method, for websites using an old redirect-based flow. The preferred way to integrate PayPal uses no redirects. At all. Your website remains loaded in the background. Do the following:
Follow the Set up standard payments guide and make 2 routes on your server, one for 'Create Order' and one for 'Capture Order', documented here. Both routes should return only JSON data (no HTML or text). Inside the 2nd route, when the capture API is successful you should store its resulting payment details in your database (particularly purchase_units[0].payments.captures[0].id, which is the PayPal transaction ID) and perform any necessary business logic (such as sending confirmation emails or reserving product) immediately before forwarding your return JSON to the frontend caller.
Pair those 2 routes with the frontend approval flow: https://developer.paypal.com/demo/checkout/#/pattern/server
If, for some odd and inexplicable reason, you insist on using the legacy flow with a full page redirect instead of what I just described above, you must include a redirect_url in your orders creation request, so that PayPal has somewhere to return to after the order is approved. Immediately when the return happens, capture the order with an API call and show the success/failure result to the customer. If you want an intervening order review step before capture, you can do this, but you must also edit your initial order creation request to change the verbiage of the last button at PayPal from "Pay Now" to "Continue" so that the user is clicking on something that corresponds to what the next step will be. application_context.user_action needs to be continue for this change.
Capturing an order will return a v2/payments object which is the completed transaction with its own ID for accounting and refund purposes. (The order ID is only used during payer approval, and unimportant otherwise)
I had this issue too, and I eventually got a solution from the documentation.
You have to add application_context.return_url to your request.
Attached is an example in PHP:
$postData = [
"intent" => "CAPTURE",
"purchase_units" => $purchase_units,
"application_context" => [
"return_url" => "",
"cancel_url" => "",
],
];
You can make a whole lot of customisations to the PayPal Payment page by adding the Application Context option, For a full list of the possible customisations, you can check up the official documentation Application Context Documentation
In Laravel Spark you can set the option that when the customers creates their account the system show them the form to fill the billing address & VAT no.
Unfortunately to have the correct data on the invoice they have to go to /settings#/invoices to fill in the data after finish all the registration process, confirming their email and log-in.
This is very inconvenient as nobody understand this step and there where 0 (zero) customers of over 500 we have until now who actually find this field and filled it up. They just complain that the invoice is incorrect and we have to send corrections.
So my question is:
Is there a way to put the "Extra billing information" field which is here /settings#/invoices on the registration front so the customer will be able to fill it in during the registration process?
I needed to follow the same steps like with adding any other field to the registration form because the company data are stored in extra_billing_information column in users table.
Reference: https://www.core45.com/en/blog/how-to-add-customera-company-data-for-invoice-on-the-registration-form-in-laravel-spark
When you change the Order status to Shipped in BigCommerce, you can put in the Tracking ID and click on the check box that says "update the order status to Shipped, and notify the customer via email". This works perfectly when I'm logged in an typing manually.
If however, I create a shipment using the BigCommerce API with CURL, I don't see any way to cause the customer notification email to be sent. I have searched every place I can think of, and there doesn't seem to be anything in the API specifications or online help. I can update shipped quantities and Tracking ID just fine.
Is there a way to also send the Shipped notification via email to the customer when using the API?
If you can create a shipment via API, that should update the order status to shipped or partially shipped which will trigger an email depending on store settings (listed under Checkout in the control panel).
I'm using the callback API to prevent someone selecting a non-UK shipping address. I've supplied a callback url, I've set CALLBACKVERSION to 61.0.
When I go into the sandbox and choose an address I know the callback page is being called as I've added code to email me the values submitted to it and the value returned to PayPal. For anything with a SHIPTOCOUNTRY that isn't GB the response is
METHOD=CallbackResponse&NO_SHIPPING_OPTION_DETAILS=1
I've also tried setting a fuller response in case it doesn't like some required field to be missing
METHOD=CallbackResponse&CURRENCYCODE=GBP&L_SHIPPINGOPTIONNAME0=Standard&L_SHIPPINGALABEL0=Standard&L_SHIPPINGAMOUNT0=2.95&L_SHIPPINGOPTIONISDEFAULT0=true&L_SHIPPINGOPTIONNAME1=Express&L_SHIPPINGALABEL1=Express&L_SHIPPINGAMOUNT1=5.95&L_SHIPPINGOPTIONISDEFAULT1=false&NO_SHIPPING_OPTION_DETAILS=1
But it's still allowing non-UK addresses and just using the shipping options set during the initial set up request.
Any suggestions on where I'm going wrong?
After opening a ticket as suggested by PayPal_Patrick the problem was that I was adding the callbackversion in the wrong place. The full response to reject a shipping address on callback is:
METHOD=CallbackResponse&NO_SHIPPING_OPTION_DETAILS=1&CALLBACKVERSION=61
There are different transaction ID's for Buyer and Seller accounts.
I think this might be an issue caused by the country associated with the buyer account being used. I'm going to reach out to the product team for Express Checkout and see if it is intended functionality or not - I don't believe it would be.
If you want to stay updated on the issue I would recommend creating a ticket to PayPal.com/mts, give me the ticket number, I'll grab it and keep you involved.
I need to find out if a customer (during checkout) is also currently logged in as a Zen Cart administrator. The purpose is for allowing certain actions to be available for an administrator placing an order on behalf of a customer (say, by telephone).
My first idea was to check $_SESSION['admin_id'].
However this does not seem to be set, instead $_SESSION['customer_id'] is.
I think this is because different session names are chosen in the admin and customer areas (zenAdminId vs zenid).
How can I find out if this customer would be logged in as an admin, had they been in the admin area at the same time?
I am working on the checkout step prior to sending off to a hosted payment service provider.
Edit: the merchant is logged in as an admin and is entering the customer's details, which are different to those of the admin account, into the checkout screens. It is a customer-not-present/MOTO setup.
You are correct - $_SESSION['customer_id'] is set. And there's nothing in the customer's table which indicates if this person is an admin. However, if they use the same email address for their customer account and for their admin account, you can look up their email in the customers table with $_SESSION['customer_id'], then match that against the admin_email field in the emails in Use this to look up table "admin."
It is worth noting that if your admin cookie isn't restricted by path SESSION_USE_ROOT_COOKIE_PATH=True that you can simply check for the cookie zenAdminID. You can read the contents of this cookie by querying zen_sessions, the sesskey being the value in zenAdminID.
You have to base64_decode the value from the result to get the session. It gives a serialised object, although unfortunately you are unable to use unserialize on it. You can load it as the current $_SESSION but this would overwrite your current one.
I simply did this to get the admin_id:
preg_match('/admin_id\|s:1:"([0-9]+?)"/', $admin_session, $admin_matches);
$admin_matches[1] giving the admin id value.