Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
Magento is a great product but out-of-the-box it really lacks recurring billing support. I've come to a crossroads with my current project and need some direction.
We have exhausted every Google search and module that is under the sun for Magento to support recurring billing the way we need it to. So far, all we have come across is one module that costs $300 by aHeadWorks in the UK. We've tried the module and are extremely disappointed so far, mainly just due to total lack of support and documentation; Nobody seems to have the knowledge to answer our questions, or even attempt to.
Our goals are simple and we cannot figure out why there aren't more solutions out there to do this, so the question becomes, what is everyone else doing?
All we need to do is the following:
Provide subscriptions for items such as web hosting, text message marketing, etc.
Tie into our merchant account and authorize.net
Keep the customer on our site at all times
Skrill Moneybookers & their module isn't compatible with what we need to do (at least in the US). PayPal sucks and wants to hold our money back and also wants to redirect customers to their site to setup a billing agreement. iTransact services are fantastic but there is one module that is 2 years+ old and has no support.
The answer is recurring billing is quite a taboo in the e-commerce industry. This is mostly because the big boys, i.e. Mastercard and Visa have very strict rules governing recurring billing transactions.
Recurring billing means storing a customer's credit/debit card data, long number, expiry, and cvv2, for future processing. However, this opens up a huge can of worms in terms of security. This is why Visa/Mastercard impose rules on merchants in becoming PCIDSS compliant. Practically this means your server/website have to be certified to be secure, using a service like McAfee PCIDSS, which basically scans your server/website remotely and attempts to break it. It looks for open ports, badly configured firewall (or lack of), xss scripting flaws, mysql injection breaches, operating system security breaches, and many more. One of the most important elements with PCIDSS is having all card data encrypted.
It is a laborious process, since once you are given a report, you are also expected to repair all flagged critical issues and pass the scan. There are other steps to complete, but I shan't enumerate them all here. See the pci dss website for reference. You are also expected to keep the certification up-to-date on a quarterly basis.
Basically what this means is that Visa/Mastercard don't particularly like the smaller merchants to have this feature, as they can be of major risk to clients. If their system is breached, hackers could use the card data for criminal enterprises.
This in turn means Visa/Mastercard favor the big players in the industry to handle recurring billing, such as PayPal, Worldpay, authorize.net, etc. One port of call, one entity to fine and recover losses if there's a problem.
And now we return to Magento. Whilst it is relatively easy to create a normal payment method in Magento, since most PSPs work in the same manner [mostly], recurring billing is handled differently from provider to provider. Furthermore, some are more restrictive than others.
I can't and won't recommend PayPal as I have had extremely bad experiences with them, I can definitely recommend Worldpay + Futurepay + Invisible XML method. You would need to hire a Magento developer to write a custom module for you, but it's doable. I am currently writing a module for a client in Norway using a norwegian payment method and recurring billing.
If you still need help, get in touch, I can write a module for your store.
Hope this helps.
Cheers,
Michael.
Paradox Labs has an Authorize.NET CIM extension that supports Magento Recurring Profiles and Braintree recently released an extension that also supports them. I have made lots of improvements to Magento's recurring profiles. You can definitely tell they are in beta form, but that should stop you from getting your hands dirty and finishing things that the Magento team hasn't got to yet.
Here are a few things I improved:
https://github.com/tegansnyder/Magento-Recurring-Beta-Grid-Improvements
https://github.com/tegansnyder/Magento-Programmatically-Create-Recurring-Profiles-Authorize.net-CIM
https://gist.github.com/tegansnyder
I'm had to make modifications to the cart controller to allow discount codes to display on the frontend when used on nominal items. By default they wouldn't display that they were applied.
I also had to make some modifications to the daily billing job that runs to remove the discounts the second time the profile is billed. Magento was applying them each time it reached the end of cycle.
Lots of little things here and there, but it's getting there.
You should look at the service OrderGroove.com. They specialize in recurring orders in e-commerce systems like Magento.
There are different strategies to implement recurring billing / product subscriptions with Magento:
Magento Recurring Profiles
Magento's built in recurring profiles feature can be used with compatible Magento payment extensions and gateways. These include PayPal, Authorize.Net CIM (Customer Information Manager). A payment extension which supports the recurring profiles feature is required for this approach, for example Paradox Labs CIM Extension.
Customize Magento to Support Recurring Billing
This can be done with a third party extension, like the (AheadWorks SARP extension) or developed from scratch.
Integrate External Subscription Management Software
Platforms which specialize in eCommerce product subscriptions include:
Subscribe Pro
Order Groove
Some subscription management software for digital goods includes:
Recurly
Zuora
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 2 years ago.
Improve this question
I am working on a small web-app as a hobby, and I would like to avoid any functionality that would trigger GDPR requirements. As such, the web-app neither collects nor processes personal data, does not set cookies (or otherwise track individual users), and also does not integrate any services that do these things.
My question is, if I deploy this app on Heroku, does Heroku do anything behind the scenes (e.g., collecting IP addresses) that would then impose GDPR requirements on my web-app?
Another way to put this would be, is it possible to use Heroku and have GDPR not apply to your website? (without preventing traffic from EU countries)
The first thing to check is hosting location. When you create an app, Heroku allows you to select whether it's hosted in the US or Europe (though no more specifically than that – you just have to hope it doesn't include the UK!).
Next, because Heroku is a managed app service, it means that they get more access than a typical VM would have. You then need to read their privacy policy, which presents a problem: Heroku is owned by Salesforce.com, who have taken a belligerent Facebook-style head-in-sand denial approach to recent court verdicts in this doc. They say in there that the ECJ did not invalidate standards contractual clauses (SCCs), which is true, but not the end of the story. The ECJ said that while SCCs are valid as legal instruments, they can only be used to manage transfer between jurisdictions that uphold EU data protection and privacy standards (which, as far as the US is concerned, has been shot down with the collapse of Privacy Shield), and this is deemed to be the responsibility of the service in question to substantiate. So, what you then want to know is where is the detailed analysis of the US legal position and the audit of the US security services that Salesforce is required to conduct if the SCCs they are using are to be considered valid?
This is of course a rhetorical question: Salesforce has conducted no such audit, nor could they do so in sufficient detail, which then means of course that SCCs are not a valid mechanism for transfers between the EU and US for any service that Salesforce runs.
That said, their privacy policy is pretty large, and I recommend you read it, though they still make reference to the now-defunct Privacy Shield, and make some assertions that would concern me. I'd suggest finding out exactly what they do with data held in EU data centres, what they do with logging, and look harder at their third-party sharing, as that's often the biggest problem area.
This isn't really the place to go further into this, so I'd recommend you read their policies, and also read the GDPR (that's not the official source, but I find it's much more usable), or find a lawyer if you want a more precise analysis. The primary focus of GDPR is on the broad principles, not implementation details, so if something seems dodgy, creepy, or overreaching, it probably is.
I apologise if this has raised more questions than it's answered!
I am currently using Kinvey only for the business logic. Everything else I am using other services. It seemed that I must be logged in to use business logic so I made one account and made the user register to that account when opening the app. I am confused if that will be an okay approach since I believe I saw on another post that after so many downloads, it will raise a flag on Kinvey's side. Is that true? I also just saw these images in the users section and am not sure what this means.
[
[
To answer your question about pricing, you can review our pricing plans at https://www.kinvey.com/pricing/.
Kinvey monitors customers in the free developer plan to check if their usage exceeds the limits. We do this by checking API calls per month, number of active users, data/file storage used etc for your kid - not by App Store downloads.
If that happens, Kinvey support or sales will reach out to you to help you transition to the next pricing tier or help you to reduce your consumption with optimization or other options.
Your queries about master secret, authentication are best answered in this Kinvey security guide: http://devcenter.kinvey.com/rest/guides/security
Regards,
Wani
Kinvey Support
There are plenty of companies out there offering texting to your landline without affecting voice service (ie zipwhip, heywire), but does anybody know what they're using? Twilio almost offers this, but it's currently in beta and only for toll free numbers. TextUs.biz has an explanation of how they do it in their faq, which explains that they have some sort of agreement with their SMS gateway provider that lets them get texts to a particular number routed to them, but afer a lot of googling I still can't find any resources on how to make it work.
(Disclaimer: I'm the VP of Engineering # HeyWire) The TextUs FAQ is spot on. SMS routing and voice routing are completely separate. OTT text carriers like us have agreements with SMS aggregators and have to abide by industry rules and guidelines. The agreements and rules may vary depending on whether you're doing short code, non-toll-free long code, and toll-free long code. International and MMS are also other dimensions as well.
In general, our application stacks connect to SMS gateways, which connect to SMSCs at our aggregator partners. Beyond that, the details of how everything works isn't technically complicated. Some the real special sauce comes in the details of all the agreements and partnerships required to get things up and running. Unfortunately, those types of details fall under the umbrella of "trade secrets". Partly due to providers not wanting to reveal too much to competitors and partly due to the agreements themselves, which prohibit disclosure of details.
Are you asking because you're trying to build something or just to try to find out some general information?
EDIT: And I just realized I wasn't logged into my account when I posted this. Oh well.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I have been doing webdesign for a small business in Denmark, which alrady have a deal with a larger company to create the final site.
Among this companys proposal, I see that they charge a rather large fee for installing Magento on my clients server, and an additional fee to integrate the design.
Same company forbids my client from having FTP or similar access to the server, and they are therefornot able to install this themselves.
My question is : is resale of the Magento really allowed by the licence? This company wants to charge a rather steep amout for even installing a blank version of it, no Magento-licencing included.
Ihave looked larger company up, and this company does NOT have a standing licence for Magento. And even if they got one, I have a sneeky feeling that something is legal/licence wrong here.
The reason I share this with you is that I have a guts feeling that I should raise some critical questions and suggest that My client uses another company for their webaite, but I need to be certain that Im on the right side.
The IT company has no partnership with Magento/Varien, and have a somewhat tarnished reputation already...
I have mailed Magento about this, but have not had any response yet.
Your question is not entirely clear. But a company can certainly charge for installing a licensed product on behalf of the licencee, this is just a consulting or service fee (unless the licence specifically prohibits a third party from doing this, which is possible (although unlikely) if a) source code is being exposed, or b) there are other commercial sensitivities such as NDAs. But then that is not your risk, it's the licensee's)
As for Ubuntu, a company can again charge for installing or maintaining an Ubuntu install, again this is consulting/service. In fact you can SELL a copy of Ubuntu too, if someone is willing to pay for it that is their perogative (and they in turn can sell it themselves). You just have to provide the source and the licence, not just a compiled binary in order to comply with the GPL.
I can understand the position of the 'large company' providing the managed hosting for the Magento build. However, I also understand your concerns.
Assuming that you are only working on the design, there is no reason why you cannot implement your design on localhost with the Magento 'demo store' products. You can then take your design along to the 'small company', get your designs signed off, archive the /skin/frontend/default/macguffin and /app/design/frontend/default/macguffin folders, hand them over to the company providing the 'managed hosting' and then collect your pay-cheque.
By not allowing you access via FTP the 'managed hosting' provider are ensuring that their clients have no third-parties able to access any-of-their-stuff. Furthermore, design is not that big a deal in a Magento build, there is also the payment gateway, the shipping setup, analytics and everything else that happens on go-live. They are also taking the responsibility of providing uptime, availability and the aforementioned security.
You and I know that you can do all of that on a virtual-private-server and get it done in a matter of days, with lots of testing but no client liaison meetings, office overheads to pay for, an expensive project manager to explain everything to, excessive time-sheeting to keep up to date and so on.
However, the 'small company' will have reservations on allowing someone other than the 'large company' doing all of that. Given that their web presence is pivotal to the success of their business, given that they may not have management resources, given the fear of the unknown, given a lack of in-house expertise, politically the solution they have arrived at can be considered as making business sense to them.
There is nothing wrong with the business arrangement from a legal/licensing point of view. From your point of view of getting the job done, you can do your design offline, i.e. on localhost, deliver the deliverables and collect your cheque.
If the deal with the 'large company' does not work out then, if your work is good, you will be well placed to take on the project, to charge 'freelancer' rather than 'agency' rates and build a long term relationship with the 'small company'. However, you are not there yet, your best bet is to forge a close working relationship with the 'small company' and the 'large company'. For all you know, the 'large company' may have other clients, and, if you work well with them (i.e. drop the suspicions and animosity-from-the-outset), then you will possibly get other design work from their other clients.
Please note: We are using Magento's Professional Edition which does not come with Vendor Support.
I've looked over previous questions, and while I can find questions and answers about multiple payment gateways on a site, I can't find anything about Magento's Payment Bridge specifically. Payment Bridge is a PA-DSS certified application that Magento provides with it's Enterprise and Professional licenses. It's necessary for a PCI compliant environment.
Our problem is that our client has two Auth.net accounts. This is for reconciliation and the explanation can get long-winded, so please just trust me that this is a necessary scenario.
When creating the merchant with the Merchant Configuration tool when setting up Payment Bridge, it only allows you to provide one login, i.e. just the one account, and it asks which cards are accepted. The site will accept all cards, but one account handles Visa, Mastercard, and Discover, while the other handles all Amex payments.
How can I set up the merchant during the Payment Bridge set up to be able to have both accounts?
Update - for now, we've created a hack in the Payment Bridge Authorize.net class that checks the card type and, depending on the type, it switches the credentials if need be.
Not a perfect solution, I realize, but it's working while we figure out something a little more stable.
If you have any ideas, please share!
Thanks.