Can anyone discuss some of the pros / cons / ease of use for Stripe's test mode vs. Paypal's sandbox testing? Specifics appreciated!
Speaking from personal experience, unless you need to accept PayPal payments, Stripe is way better than PayPal.
PayPal is way too big to really care about small developers. Just look at the number of questions that actually gets answered. In general, whenever I'm faced with a PayPal-related problem, I can expect to solve this on my own rather than asking anyone from PayPal
PayPal still need to support code from 10+ years ago that uses legacy SOAP stuff and meanwhile it also tries to come up with newer APIs. This just creates crazy amount of confusion. I might be exaggerating here but there are at least 5 ways to send a payment in PayPal, and 10 ways to receive a payment. With Stripe, it is just one API and that's all
These two are the main thing that discourages me from PayPal. There are tons of other issues like mystic error codes, slow website and weird restrictions here and there
If you can, just avoid PayPal integration and save yourself hours of pain and headache
Related
I am planning on using Twilio to conduct surveys over SMS and IVR. The surveys will assess food security risk, and will be primarily conducted in African countries.
In order to reimburse the cost of airtime, and to incentivize respondents, I would like to transfer a small amount of credit ($0.50) upon completion of the survey.
I've found a couple of websites that support this sort of transfer, http://www.digicallingcards.com/, and http://www.transfertpays.com/en/, but (as far as I can tell) they don't offer programmatic access.
Does Twilio support this? Or is there another API that supports this kind of transaction?
I work for Twilio and this is not something we currently provide.
When working with this kind of thing (mainly with charities etc) I see people use the concept of 'flashing'.
This is a well known concept in Africa, so it is worth considering. The idea is that you publish a number that people can ring. They then hang up when the phone rings but before it is answered - almost immediately. Your service or operators can then call that person back so they don't have to pay anything for the call!
May be worth looking at. Hope this helps!
I need to create an e-commerce website. I am thinking if I can use Joomla and VirtueMart to finish it. I have never used VirtueMart before. I am just worrying about if this solution is great. VirtueMart is a shopping cart… is it easy to link it with payment gateway from different banks? Is it secure? Thank you for any suggestions. Many thanks
Virtuemart is probably one of the biggest shopping carts available for Joomla. It's one of the most comprehensive to my knowledge and I believe that it will accept payment gateway from different banks. How easy that is to setup is a subjective question... it would depend on your level of comfort with those things. In my experience Virtuemart is very full figured, secure and is a great ecommerce platform. Since they've released it for 1.7 it should in theory work with 2.5 (the LTS release). Their support has always been highly reviewed and the user community is large as well.
I've used it before in the past with great success but the sites were much more simple and didn't include working with multiple banks - just paypal support.
Anyhow, I hope this information helps!
I'm a non-technical (well, non-software. hardware background) founder who has hired a pretty good developer that has built a site with backend on Rails and frontend with CSS/HTML pretty capably. our next step is to develop a Yodlee integration, and we both want to know how long it takes to do this. He has an estimate which I think is reasonable, but would like feedback from the community without biasing the responses.
Also, if anybody has done an implementation before, I would really appreciate your perspective and help!
I have implemented a complex Yodlee integration for a LA based start-up over the last two years. They built a social game and money management platform on top of it. The short answer is that it's tough and dirty work.
The technical aspect of getting your application to communicate to the Yodlee API is not at all the hard part (its pretty much a standard web service). Following are some aspects highlighting the difficulty:
The most difficult part is dealing with the unknowns and the variability in the client data.
There is effectively no documentation for the API
There are several way to do each operation that will return different data
Ive been designing and building systems for 15 years and have gotten pretty good at estimating projects. We were way off with Yodlee; in fact we are still dealing with issues.
In order to understand why its so tough, you really need to understand what Yodlee is.. it is an aggregator of 10,000 different systems. Now these other systems might be big professional systems like Bank of America, Chase, ... but they are often small little banks (Bob's Bank in Omaha).
When Yodlee communicates with the big companies (they are called content services) there is most always an api that actually returns good data. But with the little ones, they are doing screen scraping. You can imagine that breaks all the time. They have an entire team in India which is just focused on that.
The other issue is about modelling the data; each of the content services at its source has modeled the data differentley (different names, different elements, different relationships,...) but Yodlee but combine all 10,000 models into one view. What this leaves you with is a very bloated model, where you can never know or count on getting a certain data element.
To give you an idea... there are extra fields about a credit account (apr, credit amount, last payment, ...) beyond the standard base'class fields (balance, ...). While this sounds great that you have this data, in practice the number of content services that provide these extra data elements is so low that you cant really depend on them. I'd say that the fidelity of those data elements is very low. All you can really count on is the base elements (account name, type, balance) and (transaction date, description and type).
Speaking of transactions... their transaction categorization system is not that good. They have clearly taken a breadth first approach to this, rather than focus on accuracy. We built an entire system for transaction categorization which is far more effective.
A couple other things: The DAG account test system is useless; it does not operate the same way real accounts do. You will be far better off opening 5-10 accounts at different content services and giving your developers the username/passwords for these for testing. The MFA (multifactor auth) system for account security has been an endless headache. This isnt Yodlee's fault, its the nature of the game. The banks are doing more and more crazy things that add security layers. Yodlee has the MFA system in place to compensate for this. At any given time about 20% of our accounts are in error for some reason. We have built an entire component just to manage this.
So what does this all mean? Double your estimate, get ready to get dirty. I dont want to put Yodlee down at all (except for the lack of documentation); they really are solving a hard problem. There really arent any other better options.
I run the team responsible for sales and support of the Yodlee APIs so the response may be a little biased.
I have seen clients get up and running in anywhere from 10 days to 3 months to 6 months. The time to implement depends on the number of fields in the data model you are using and how you are going to use the data or manipulate it before presenting it to your users.
While the most prevalent data fields such as account balance or transaction amount will always be available, Craig is right, as you get into the broader data model you will have to code for exceptions when the data is not there. Yodlee does provide documentation on how often the fields will be available to help with this process. But if you are only going to be using basic account and transactional information, you will not have to worry about these complexities and it will speed implementation.
How you use the data once you receive it from Yodlee will also play a big part in the time it takes to get integrated. If you are deriving additional data from the transaction descriptions or are doing something with categorization then there is more complexity and it will require more time. If you are using many of the fields as-is, then this will be easier.
The other item that Craig mentioned is the extra security questions (Multi-factor Authentication). While that section of the API does add some work, we have added documentation around this to make integration easier. Also, with any development issues that come up we give clients access to a developer forum that is monitored by our Technical Consulting team.
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 8 years ago.
Improve this question
I have begun work on a personal project that may end up having some real-world applicability. I am beginning to entertain the idea of selling licenses. I am sure some others here have done this before, and I was wondering what successfully processes you've used to do so.
There are many questions on SO regarding licensing, legal implications, etc. However, I have looked around and could not find a duplicate question for this one. To be clear, I am not looking for information on what licensing strategy to use, how to advertise your software, and so forth, but rather, for a checklist of things that should be done to increase the probability of success, and any possible gotchas I have not thought of. If anyone has any personal success stories, they would be very welcome.
For a little background, I am set on the idea of licensing a closed-source, compiled .NET DLL.
A few things off the top of my head:
Strong documentation, because formal technical support is unlikely
Specifying licensing terms and formalizing them with an attorney
Code obfuscation
Exploring license enforcement (either using a commercial package or custom code)
Building a website around the product, including real-world code examples since this is a library
Possibly offering some type of beta period, for feedback and getting the name out a bit
Offering instant/automated purchases
Marketing (oh boy)
Is it necessary (or wise) to start a one-man company to do this?
I will keep this list updated as answers come in. Thanks all!
Some tips:
Obfuscation: Be wary of obfuscating everything. An alternative is to obfuscate just the critical bits (licensing, premium features). The problem with obfuscating everything is that stack traces from error reports are ineffective. When an unexpected exception is caught, you'll want to give the user the option of automatically reporting its details - this really helps with QC.
License enforcement: If it's a utility that can be easily pirated, people WILL pirate it. An activations-based licensing system is ideal - and if it's not too draconian people will be less motivated to circumvent it. For instance, allow at least 3 activations per user (home computer, work computer, laptop). If it's a control library, then an activation-based may not be required - baking the serial number into the library may be enough because customers are unlikely to build their own product on a stolen assembly.
Instant/automated purchases: writing a custom licensing server and web page for this is fairly easy - you need only about 3 tables. LINQ to SQL is ideal for this sort of thing. For the payment gateway, I use PayPal - it's very easy to set up, has the features you need for selling activation codes, and allows multiple currencies. If you use PayPal, enable both PDT and IPN so you can give customers their activation codes both on the screen and via e-mail.
Marketing: try LOTS of things simultaneously - because it's hard to predict the success of any campaign. Especially without experience! Making yourself known amongst the influential people in the field into which you're selling can work very well.
Advertising: advertise on StackOverflow - that's what I'm doing! Google ad words is also worth trying because it's so cheap to set up - you'll know after spending $10 whether it will be effective for you or not.
And good luck with it!
You have most of the practical things listed out, in terms of actually getting a product from you to the customer -
However, there are a couple of things I'd also recommend.
Figure out how you want to handle all of your accounting/purchasing/billing/etc.
Rethink formal technical support (for money), but not at the exclusion of documentation
Talk to a lawyer regarding all of your licensing decisions, agreements, etc., as well as company structure
Talk to your accountant (and/or find one who is good at working with small tech companies)
Some of this will cost some money up front, but save headaches later.
The last two bullets are crutial - there are MANY options for how to setup yourself from a tax perspective, each of which has potential advantages and disadvantages depending on your specific situation.
For example, if you're in the US, there are many advantages to incorporation prior to doing anything on your checklist. If you decide to incorporate, you may want to do it in your state, but there are also advantages to incorporating in Nevada or New Jersey (very pro-corporate states legally). If you're successful, doing this early can save a huge amount of work over time and have significant benefits.
Also, if you incorportate, you might want to consider S vs C corps (S Corps are great if you're a one or two man operation). If you don't incorporate, you can run as a sole proprietorship or an LLC, both of which have advnatages and disadvantages. A lot of this depends on your product (what it does), your expected returns, etc. - having a good lawyer and a good accountant is a huge blessing.
If you're aiming at software development teams as customers then the sort of thing they are likely to expect to see (in addition to the ones you listed) are:
A download service for any additional items and/or patches that the user might need.
Tight version control/configuration management processes so that it's easy to find out what version of the product they have, what they need and what the differences are between versions.
Email/online bug reporting.
A demo/trial version of the product.
A good set of tutorials.
Community support e.g. developer forums. This is a good 'value added' service that can also help with the fact that you have concerns (as a one man company) over being able to provide 'formal technical support'. Hand out a few badges and reputation scores and get a free technical support team ;) ... but if sales take off, seriously consider providing 'formal technical support', it can make a huge difference to the perception of the product.
... and make sure that the website, download service, license server, forums etc are all properly secured and done to a professional standard. If any of the peripheral services are less than 100% then it all reflects badly on the product, especially when yours is a technical one.
You might not want to provide formal technical support, but you could look for creative alternatives like some sort of moderated forum for issue resolution. Also, provide at least an email address for someone to contact you.
Another thing is to hire some sort of designer to make your product, documentation, website, etc look good. It is generally easy to tell programmers who attempt design.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm trying to land my first programming-related job, and I found a website for a company which is accepting resumes for an eCommerce development position.
This is the requirements they listed:
To be proficient in:
HTML (hand-coded)
CSS
PHP
Javascript
MySQL
Preferred skills:
PEARL
Linux
The fact that they (unless they're actually using the PEARL programming language) misspelled perl and have a fairly bland portfolio aside, I can do all of this--I mean, I need to touch up on my Javascript and learn a bit more MySQL--but I can do all this, and I'm sure I can pick up perl in no time. But I was wondering--what exactly does an eCommerce developer do? Is this like, building shopping carts? User login systems? Or does it just mean doing everything except design on corporate websites?
eCommerce has one big word that goes with it Security.
Do you feel confident writing secure code? Bearing in mind that your code will be handling the users credit card information.
Now, there is alot that goes into building an eCommerce solution from the ground up
Product Listings
Adding/Removing Items
Sort by size/shape/price/color/...
Search
Filtering results
Shopping cart (harder then it sounds)
Database or Session?
Adding/Removing Items
Checkout
Integration with payment API
Reporting
Inventory
Security
XSS
SQL Injections
I would suggest that ecommerce is so much more than a specific technology. ECom is more about how the database is built and the features that are required. There is a good book that I read 10 years (a long time) ago that goes into ecommerce with asp classic. But there are many new ones using newer technologies here.
The big key is how you structure your data, products, options, orders, order details, credit card/user data, etc. Also, the various ways of processing transactions. How to handle order pipelines. When to offer navigations away from the current page and when not too. How to make product recommendations. Dealing with tax API's and shipping API's. You might consider downloading DashCommerce (a .net application) or something similar that fits your preferred technologies to see how they have set things up. Install something. Get it set up to feel the pains for data management. ...also to feel the pains of navigating a shopping cart (adding products to the cart, updating the cart, checking out, setting up an account or having an anonymous checkouts).
Being an commerce developer generally means knowing how to work with Verisign (now paypal) or similar payment processing. How to intercept fraudulent transactions and deal with them appropriately. How to work in a high transaction environment (caching, tierd architectures, queues, web services). Cross linking products based on user history/profiling to maximize transactions (think candy at the check out stand of a grocery store). Knowing how to work in a secure manner with sensitive data which generally means encryption techniques, setting up DMZ's, working with proxies, etc. Take a look at using some form of a rule engine for order pipelines so that your business rules are separate from your application logic. Understand coupons schemes, discounts, etc. Frequently ad campaigns are heavily used for generating side income.
Ecommerce can be a big topic!
It all depends on what you are working with.
I have been working as an e-commerce developer for half a year now.
I have used the Magento platform for all of my work.
Since standard Magento is already very secure you won't have to do much security code.
Mostly you change the layout and the design of the standard Magento shop and add any new features the client wants.
Most of these can be achieved by downloading custom modules built by other developers or you can build them yourself. Building a Magento module the right way is quite difficult for someone who is kind of new to programming or new to Magento.
I know this topic is rather old, but i thought someone might still benefit from this answer.