Magento - Create order from backend - magento

I'm creating alot of special offers for my customers, which I need to be able to send from inside magento. This is already possible by creating the order from the backend/sales. But the customers will only get an order confirmation and not be able to pay for the order they recieved in their mail.
Is there any module that would make customers able to pay pending orders from their login?
Can't seem to find any? Surely I'm not the only person creating an order with special prices for some customers?

There is Advanced Point of Sale module we use for taking phone orders. It isn't perfect but is far better than trying to use the back end.
There is also a plug in for alternative payment method to allow your phone person to handle payment on the back end. We've got that one, too.
And then there is True Order Edit, which we consider essential / requirement for running an online business.

Related

Magento marketplace with vendor payment

I'm using marketplace extension from magentoconnect in my store. This extension is really good and works exactly what i needed it to do but there is 1 particular requirement I need which it doesn't provide.
For vendors, I want payments of each product sale to go directly to vendor's account ( through their credit card etc which they need to add before their product becomes visible ) and commission amount ( some percentage which is set by marketplace through admin panel ) to go to site owner's account. I know there is paypal adaptive payment add-on available with this extension but I don't want to use paypal due to some reasons.
I have tried to create my own module which will gather vendor's payment method after their login and will verify it if their credentials are working or not. But i'm confused as to which approach should i use to get their order payment to go directly in vendor's account and commission in site owner's account right away.
Also, i want to use authorize.net to charge clients as stripe does not support a lot of countries.
Any help in right direction is very much appreciated. I need a solution as to how i can implement it. I can customize or create my own module if needed be for this particular case, but i need to know which is a better approach or what will be close to magento way of doing stuff.
Sorry for my bad english.
Thanks In Advance
Ab.M
Hi Regarding Paypal adaptive payment this thread will help https://www.paypal-community.com/t5/About-Payments/Adaptive-Payments-for-Magento-marketplace/td-p/968101
as authorize.net does not provide marketplace api like stripe or paypal provides so it wouldnt be possible in this way .
PS - we are not self promoting our plugin or product , as user asked the questions specifically about our product that why i have added extension link with images and screenshot

Paypal delayed chain execute payment to specific receiver?

I'm working on a Magento marketplace where the client would like to use paypal delayed chain as payment method. Here Client will hold the vendors payment for 15 days and then execute payments. The scenario is Client don't want to hold payments for highly credible vendors. He wants to pay them right away. But in delayed chain, we can't execute payments based on vendors. When the time comes to pay vendors, all vendors will be paid at once based on transaction id or pay-key which used to create payment.
I need to implement this scenario in Magento. Does anyone have solution on this potential issue?
After digging deep about this issue, I found that paypal doesn't support what I asked from their API or the API is still isn't matured to accommodate the need. So we went with another solution to overcome this problem. Solution is not efficient but it's the only working solution as of now.
We have to go with checkout by vendor, so that we can execute payment based on vendor since each order is associated with a vendor.

Should I use Recurring Profiles (Beta) for my recurly recurring payments module?

This probably seems like a stupid question off hand, and maybe it is actually, but there are a few specific reasons I'm leaning away from using them. The paypal recurring profiles implementation seems like it doesn't work very well for a couple reasons:
There are a number of bugs in the process, including that new customers aren't created for first time checkouts using it.
Orders don't seem to be created for Recurring Profiles - maybe I have something misconfigured...?
Recurring Profiles have a Related Orders association, which is empty for my tests.
Apparently, Transactions are supposed to be used for recurring profiles (I read that on another thread recently), however I don't see those being populated either, needless to say.
What I'm leaning towards is the following:
Products can be associated to Subscription Plans within Recurly
During checkout, if a product with an association to a Subscription Plan is in the cart, the Recurly payment method will be available.
Upon purchase, an account and subscription will be created for the Magento user account.
In addition to the Order that is created, I will create a Transaction and associate it to the Order.
On the successful_payment_notification, I will insert a fresh Transaction against the original Order.
In the My Account section for the end user, I will extend the order detail template with a list of transactions.
Having a config option to suppress the Recurring Profiles section from My Account to avoid confusion on the part of the end users.
I'm sure someone much smarter than me has thought through this already, look forward to any insight you may be able to offer! Thanks!
UPDATE: My original question was kind of broken into two parts: one being why aren't my recurring profiles working even with PayPal, and the other being - does it make sense to use Recurring Profiles for my subscriptions feature. I didn't really get any answer for the latter, so I accepted the answer that was given to assist with the former issue.
I have since posted a new question related specifically to the question of whether or not to use Recurring Profiles: https://magento.stackexchange.com/questions/3202/should-i-use-recurring-profiles-for-subscriptions-feature
I have same problem and just found this:
Working with Recurring Profiles
where written that:
The Related Orders tab lists the orders which have been created according to the payment system notifications referenced by this recurring profile.
Important
To have information updated on the Recurring Profile View page, Instant Payment Notifications (IPN) must be set up in merchant account of the PayPal payment system.
I guess this is the solution to the problem

Magento: Confusion with Recurring Profiles and Authorize.net ARB or CIM

The next big topic in my new start-up company is recurring billing inside Magento. We will have a few recurring products we'd like to offer alongside some standard one-time products. I've researched the best gateways and so far we think either ARB or CIM from Authorize.net is the way to go.
Some questions come up though such as:
If Authorize.net is going to handle the recurring aspect, what is the point of Magento's built-in recurring profiles system? As far as I can tell it's to integrate with the 3rd party by actually taking the user to the 3rd party site? Using Authorize.net would eliminate the need for recurring profiles right?
Are we limited to purchasing one of two or three $300 modules out there to get started with ARB or CIM? So far Magento only supports SIM or DPM. Or do I have to sit down and extend the built-in Authorize.net payment method? Basically I am trying to say we are on a start-up budget and $300 is a killer at this moment.
If we went with ARB over CIM that means if a customer came back to purchase a second item later on that they would have to re-enter their information (CC #, exp. date, etc.) whereas CIM would have this ready to go...is that the correct explanation?
We need the flexibility to create unique payment schedules during checkout. For example: We will sell a custom website and hosting package. We want to charge the user 50% of the website cost upfront and 50% upon completion and setup a recurring payment for the hosting package all at time of checkout.
Along with question #4, currently Magento's recurring profiles limit nominal items to be purchased separately than regular products. This is not acceptable for us and a customer must be able to purchase all wanted items together in one checkout page.
Sorry for this lengthy post but I'm very curious to see what our options might be given all we want/need to do. Any advise is good advice!
The Magento recurring billing code allows customers to view and edit their subscription inside the Magento webstore, so there's no redirection to third party.
Short answer: yes, or roll your own.
I believe that is the case, but you need to check with Authorize.Net on that.
Not sure what the question is here?
Then refer to your earlier question on this topic that I answered. You can choose to override the core functionality, but you need to familiarize yourself with the reasons why Magento chose to enforce that restriction. I believe that is likely due to a restriction in the Paypal interface, and other recurring billing gateways such as Authorize.Net may be able to cope with one-off and recurring items in the same transaction.
HTH,
JD

Magento - Product Alerts Without Registering

Does anyone know if it is possible to allow users to sign up for product alerts without registering? Ie. by just entering their email.
Doesn't seem like this is a default option.
Cheers!
As I am sure you have noticed this is not standard functionality. However, IMHO product alerts are not ideal anyway as there is no means of finding out what product alerts you have, i.e. a report.
If you only have a few product alerts then you may want to develop your own solution purely in template code, i.e. with a CAPTCHA and simple email submit box that talks to your own php script (to then email you the product + email). You can then correspond with the potential customer to offer them an alternate product, place a special order for them and so on.
From a programming perspective the above is a 'non-solution', however, from a customer service perspective you can do a lot better than the normal stock alerts.

Resources