i am developing an affiliate site.
it uses linkshare and commission junction.
it is for our client. so i do not have any account with any network or agent. either with popshops or the networks.
the client has registered with popshops to display merchants.
when users click links we need to know which user had purchased which product by sending some information to affiliate networks using the sid option.
every thing fine except a sandbox.
how do we do a test drive with link share and commission junction?
else we have to wait till an user purchases a product.
any suggestion and comments would be helpful.
They don't offer a sandbox, you will need to just know what the API results will be.
It is pretty well documented, but that's all they offer.
If you want, I recommend buying something from one of your affiliates and use that piece of info for testing. Most affiliates don't mind, and I have never found anything in a contract that mentions the affiliate using their own link.
Related
I will need to build an ecommerce store. I cant really wrap it around my head so far, but my main vision:
I would pay a monthly fee for a solution (something like woocommerce or shopify) so I can keep my products online in their database. Also this solution would have all the needed things bundled (like emails, order trackings, inventory, reimbursement). It would generate an email or other sign to my client when an order happens. I can imagine this happening on Wordpress with some pre-built templates.
Here comes the second part, because I would prefer to build the front-end on my own. Do You know any solution where I can simply communicate with GET / POST requests to the endpoints. So when webshop loads the products would be rendered with CSS to the users. In case of order (linked to STRIPE most probably) the required details (SKU, Quantity, user info) is saved and sent towards the solution.
How would You build it? What would You recommend as a service?
Regards,
Koppany
I'm much aware of one company known as Scale Labs which provides the cross-border e-commerce solutions and all kinds of services related the e-commerce sector.
You can also take the help of alternatives to Scale Labs which includes Pitney Bowes, Acommerce asia, etc but personally, I have gone through the Scale Labs. They helped me from scratch and now am earning a good profit from my store. Here's the link to their official website: Cross-Border e-commerce solutions.
If you are still confused then let me know. Thanks
I intend to develop a client for Amazon's Marketplace webservices (MWS). My requirements would be to update the order, synchronize the order status, get the order details using the APIs they have.
However, I could not find a Sandbox environment to test these scenarios. Amazon has a payment Sandbox I understand, but is there a sandbox available to test these web-services? If not, are there any pointers on how to go about testing the above mentioned scenarios with Amazon MWS?
UPDATE
As seen in the comments to this post, Amazon no longer provides a staging / test environment.
I just had a conversation via sellercentral ticket with an amazon employee.
They said:
We can provide you with a free Seller Central test account to be used in ungated categories only, which are the Amazon categories that do not require approval to sell in. For a list of ungated categories, please scroll down to the middle of the page here: http://www.amazonservices.com/content/sell-on-amazon.htm.
For orders:
After you’ve logged into the staging site, you then need to log into a real Amazon buyer account (not your staging account) to buy items. Then, navigate to the offers you’ve created. If you want to buy anything from your staging account (in order to test MWS order functionality) you will be using real credit card data, so make sure your offers are priced at only one cent, and your shipping is also set to one cent. These offers will not be visible on Amazon .com. Do not buy from any other sellers on the staging site.
So (conclusion): Just file a ticket** and tell them you want a seller central test account like this!
First register** for an account that you can access seller central with (please note, that some kind of accounts have a monthly fee, so choose a "per sale" plan. This fee won't be charged with your test account), then you can file the ticket (click the link above).
All resources about the MWS API are here.
** Replace ".com" with your local Domain for the Amazon Site you want a test (staging) account for.
You can use the scratchpad of Amazon:
scratchpad
good luck
I have a website and I would like to implement a paid subscription service. Its a simple service with only 2 types of plans. For now, ill just use Paypal. But im a little lost before start, mainly with the data model.
My main question for now is, what information do I need to keep for each subscription? Do I need to implement a shopping cart for this (dont think so)? Im not asking for a detailed explanation, just a few lights or resources to find a way to start. Thanks.
Depends on what technology you're using. Basic payments work a bit like this
-> You send them to paypal with a plan (you define the plan on paypal)
they know which amount to charge
you can pass custom parameters which they will pass back
Customer fills in application
<- paypal tells you that your predefined plan got purchased
in this same request, they send a lot of info about the payment including a GUID and your params
-> you ask paypal "hey, some one just told me this plan GUID got purchased, can you confirm"
<- paypal service returns 'yes'
-> you take the customer's ID from the params that you attached when you sent them to the paypal service and update them to "paid" in the database, or whatever
That's it in a nutshell...
Look at any subscription card mailer from any magazine and you can get an idea of what kind of data you will have to record. Start and end date for the subscription would be a good thing to keep, and what kind of plan the user is subscribed to. Once you have the end date, you just need to run a query to get the records of the users that have access. Something like
Select * from users where subscription_end_date is >= today
I'm sure there will be a lot of other columns that will go into your final product, but that will be up to you to decide what data you want to keep. What are the different states that a subscription can be in? Can someone be subscribed to both services at the same time?
PayPal does a decent job if you want to charge the same amount every month. However, if you anticipate your users making changes to their subscription plans (upgrades/downgrades) or needing to provide credits to their account for customer support purposes, PayPal would require that you cancel the subscription...and then have the customer re-subscribe.
[Full disclosure - I am a co-founder of Recurly.com]
Recurly handles the upgrades and downgrades, and provides automated customer emails to be sent out to your customers (on your behalf) for every event confirmation, and invoice that occurs. You also have a full account management dashboard and reporting so that you don't need to build this yourself.
Best of all, if you ever decide to leave PayPal, and move your business to a standalone payment gateway, Recurly stores all of your credit cards in a PCI compliant vault so you don't need to ask you customers to come back and re-subscribe. (PayPal will not return your customer credit card information). You simply configure your new gateway in Recurly, and payments will be processed without any interruption to your business.
Here is a blog post we wrote on the topic:
http://blog.recurly.com/2010/08/top-ten-reasons-to-use-recurly-vs-paypal-for-recurring-billing/
-Best of luck.
-Dan
Not sure whether this question makes sense on SO, but I'm working on a website that would provide a list of new cars of interest to the user, a bit like autotrader.com. Do you guys know how this type of websites operate? On autotrader.com I was thinking that maybe the dealers have to upload and update their inventory themselves. Does anyone know whether it is the case? Also I felt that when you go to a dealer in the US, they can search for a specific car through all the dealerships.
Bottom line: The inventory seems to be accessible by third parties - who knows more?
AutoTrader gets its data by
Dealer manually adding the vehicles
Dealers third party services pushing the data to AutoTrader nightly (FTP or Emailed) from services like.
website providers / inventory management tools such as AutoJini.com, VinSolutions (now owned by ATC)
Lot management companies such as Dealer Specialties, KBB CDMData (these companies come to the dealers lot and take the pictures and then send the data out to website providers, classifieds sites etc.
feed processing company like Digital Motor Works.
or AutoTrader is pulling the data from the Dealer Management System like (Reynolds & Reynolds, ADP, Arkona, etc) pull method is mostly used for new cars.
Inventory is normally not accessible by other third parties... however one can always get the data for most dealers in the US via API from Oddle or Vast and Edmunds.
I should also add that you can get a custom crawl of all the data on ATC & cars.com from 80legs.com. This kind of service is used by companies that do pricing analytic for dealers.
You can also try contacting the website providers or the lot management companies and get the data feed from them.
There are an ISO 3779 (Europe) and FMVSS 115 (US & Canada) standards for all the cars on the market.
Each and everycar is identified by a VIN (Vehicule Identification Number).
I think that is what you are looking for.
You can get the official well-updated VIN data here
If you want to find it another way, google as usual will be your friend.
You can pull dealers inventory (active and historical) using Marketcheck Cars API
You can use Marketcheck Dealer ID or the source website domain for the dealer you are looking to pull the inventory.
Pull active inventory by dealer ID -
http://api.marketcheck.com/v1/search?api_key={your_api_key}&dealer_id={dealer_id}
Pull active inventory by dealer source website -
http://api.marketcheck.com/v1/search?api_key={your_api_key}&source=www.sanleandrohonda.com
More cases documented at the official API documentation
You can sign up at the developer portal hosted here and obtain the API key to start evaluating the API.
I have seen a disturbing trend where websites are starting to require verification sent to cellphones by text message (SMS). Gmail and Facebook are two of them. What I want to know are the following:
Is it a good idea to start requiring cellphones instead of emails now?
How do I do it on my own website?
Edit
Here are some of my new questions on the topic in response to the answers:
I see that most of you are saying that SMS registrations is ok. But what about the people who don't have cell phones? And why is it accepted to give out your cell phone information freely?
Do those big providers really pay per message to a gateway service? Is it not possible to set up a server with the correct SMS software, or at least buy a subscription directly instead of having a middleman?
Most SMS Gateway services have some kind of API. An HTTP interface seems to be the norm.
Just make sure you sign up for a service that allows receiving of messages because not all do. It's more work for them since they have to send some kind of data back to you.
Some services offer send receipts too which lets you see if the receiver got the SMS.
Some examples follows.
Esendex API docs
TxtLocal
In regard to question number one, I think Commander Keen's advice is sound.
It is a good idea if you want to limit the number of fake accounts. I see it used lots in local newspapers here in Norway. I guess it makes people think twice before posting useless crap on their discussion forums.
But do you really hate your users that much? Gmail and Facebook are big enough now that people will accept jumping a few hurdles to use the service, but you need something really interesting to make the user accept this inconvenience.
SMS is the reason I can't use App Engine ().
The first problem is that some people do not have cell phone. I can use Facebook almost completely without validating cell, but uses CAPTCHA to get through certain actions. Therefore, CAPTCHA is one of the good alternatives.
I personally think, cell phone stuff belongs to cell phones and should not be in the Web.
What if every forum admins and newbie PHP developers in the world used SMS validation and someone hacked (cracked) into their database? Do you trust a small forum? Is anti-fraud measure required so desperately?
If your site is very large and popular, it may be good to get SMS validation.
As a member of CS Networks Support team. I am going to give you some answers.
People use their cell phones as a medium of verification, so the service providers can be sure that registered member is not a bot or something else.
Yes it is true. Big providers pay for SMS gateway services. Yes it is possible to have an infrastructure like that, but it is recommended that you have a team of people that are in this business for a long period of time.
The one main reason for using SMS as a way of authentication is that you link the account to a mobile phone, which effectively reduces the chance of fake user accounts by a very large margin.
To implement this feature, you will need to sign an agreement with a SMS Gateway that has coverage for the countries (and operators) that your customers are located in..
Most SMS Gateways can easily be integrated in your software, and will most often provide you with access to all the mobile operators that you require.
I would not recommend using an email to sms gateway if you can use an API, as these are most often less responsive than using a proper API to send messages, where you will get a live connection with the SMS gateway itself, not an email server in front of the gateway.
Examples of SMS Gateway providers:
PSWinCom - www.pswin.com (Note: I am employed in this company.)
Clickatell - www.clickatell.com
HSL - http://www.hslsms.com/
Answer to 1st question: One reason which I can think of that led Gmail and Facebook to follow this trend is the emergence of bogus accounts. Now-a-days, there are use-n-throw email availabe for free like www.10minutemail.com which gives u an email address for 10 minutes. So the use can take such an email address and start a new account in the site.
But in the case of 'sms'-registration, I dont know of any such use-n-throw service provider. So everyone needs to give his own number for registration. This leads to registration by legitimate users.
Answer to 2nd question: This depends on which language u are using. Moreover, you may need a SMS gateway to achieve this.
Since you dont care about the language, try to look for SMS gateway for sending sms through computer or your web server. Some of the cellphone network providers provide an email service to send sms to a phone. For example, you are sending an sms to +910123456789 of 'xyz' network provider, you just need send the sms in the body of an email with the to-address as +910123456789#xyzmail.com
'xyzmail' part of the mail address will change according to the network provider. Plus this option is not found to be reliabe.
check out TeleSign.com
they offer phone verification solutions that you can implement into your website
phone verification is a way to reduce fraud and spam significantly
There's a trust issue here that goes both ways. If you're the provider of a service that can be spammed, you can trust that your users are people and that their email addresses are legitimate. This is probably irrational. Or you can force your users to trust that you'll deal with their cell number information safely. Many users will feel this is irrational.
And then there are people without cell phones (I happen to be one). Most discussions on the web aren't very important, but if you're trying to foster a discussion on anything important, limiting the discussion to people that have cell phones and know how to receive text messages will limit your discussion to the viewpoints of the rich and technologically savvy. If you're providing an important service like email, a texting requirement sets up a barrier to entry and saps the democratizing power of the web. It amounts to shunting the cost of your spam problem onto the disadvantaged. To me, that's unacceptable. Again, though, if your site is just inane pop culture or a marketing exercise, as most are, who cares, go right ahead.