ActiveMerchant Paypal Gateway/Express - ruby-on-rails-3

I'm trying to integrate ActiveMerchange and PaypalExpress into my site, but I'm getting confused along the way. I've googled all over the place and watched several RailsCasts, but am still a little confused.
In my app, I'm wanting to sell credits. The "products" to purchase are simply credits. They are not actual objects, nor are in the database, but are simply in a hash, for example:
# 1 credit is $5, 5 credits are $25
{
'1' => 5,
'5' => 25
}
I do not want to use a Cart system like it shows in many online tutorials, I simply want the user to be able to select an amount of credits from a dropdown list, click "Checkout with Paypal", purchase the credits, and have it update their account.
Can anyone guide me through this? I hope this isn't asking too much.

I would recommend using Express Checkout. This makes it very simple to process any amount you need no matter how you're calculating the total.

Related

Shopify - Override Quanity Pricing

I have a helicopter tour company that wants to use Shopify to sell their tours however they have some unique options for thier pricing.
1-2 people (same price) $x 3 people
add $120 to $x 4/5/6 people
add q/w/e to $x
How can I manipulate the price based on quanity. I've looked into volumn based discount apps but problem with these is that it applies a discount code. If if I added 2, it would show 50% off.
Not using Shopify plus, so no access to the script editor.
You really do not need any custom App or other problematic install for this. You get 100 options for prices. There are zero helicopters in 2022 that fly more than 100 people. Therefore, you can arguably set a variant for each number of people that wish to fly, and assign the correct price. If you are fancy, you could then tie those to the quantity selection.
In other words, vanilla Shopify will work fine for you.

Where is the information located in Magento on a sales order for discount information on the API

I just want to start out this post by saying that I am not a programmer, nor do I play one on TV. I have found this site because I have been trying to manage our Magento instance, after pretty much left high and dry by the developers we had building this for us. I will try and explain it the best I can below:
When we apply a shopping cart coupon to the sales order, and the discount is applied to each item, a new line item total is configured by Magento. We then have a connector that takes the information from Magento's API and it is then connected to Open Bravo, which is our ERP accounting software. Open Bravo is grabbing the information as it normally does, however it doesn't see the discount information, so the order total is different in our accounting program then what Magento has. Open Bravo is teling me they need to know where the discounted amount on the sales order in Magento is on the API. It's obviously in a different spot then the standard sales order amount.
I might be able to describe a little better if you hit me with questions. Any help you could provide would be highly appreciated. Maybe we could barter for some office supplies, as that is what we sell.
Thanks!
If you are using Magento API to fetch order information from magento, then below link will be helpful to find actual value.
http://www.magentocommerce.com/api/soap/sales/salesOrder/sales_order.info.html
It seems that your ERP is storing "base_grand_total" value in stead of "grand_total".

When should the Ecommerce tracking take place?

I am implementing Google analytics onto a ecommerce site. We are already tracking events like adding to cart, removing etc using the event tracking. I would like to know what is the ideal time to use the ecommerce tracking apis (addTrans & addItem). Here are my questions:
Should I call these functions for each product being added to cart?
Should I call these functions only when the payment is complete and them while displaying receipt screen?
What is the ideal way of implementation? please provide best practices if possible.
Thanks in advance
I would track few things,
1.How many got into payment form and failed to buy, which can indicate to you that something wrong with payments or page itself. Count number of visitors in checkout - number of orders.
2.How many users got into site and haven't added at least one product, which will indicate that something wrong with advertisement, landing page or website layout in general. Number of unique visitors - those who added at least one item.
Adding statistics for each product added to cart shows you what? If users buy certain product you can get that this product is most wanted but in cart means noting imho. As for your second question, i would implement my solutions written above.
I wonder if your customers should go to an externally hosted page to make a payment. If they do, then GA tracking will not show you the real source of your profitable traffic - it will show you the payment processor page as the source.
It is recommended, or at least suggested, that you place the eCommerce tracking that includes the _trackTrans call on the "Thank You" or "Confirmation" stage of your checkout process.
Also, it's worth noting that if the user refreshes that page that the tracking is on then the code will be fired again and you may see skewed figures in Google Analytics.
I was like you, I also implemented the event tracking first but I wanted to get a chance to implement the ecommerce tracking to get some $ data in there to browse. So, on the developers page. One of the examples is on the reciept page, but on my implementation that wasn't going to work since I am use a payment API. So, On my checkout page I setup the parent transaction. using :
_gaq.push(['_addTrans',
'1234', // transaction ID - required
'Acme Clothing', // affiliation or store name
'11.99', // total - required
'1.29', // tax
'5', // shipping
'San Jose', // city
'California', // state or province
'USA' // country
]);
Then when I am listing my items in the cart, I use PHP and a foreach to dump each item, sku, price per item and quantity into the parent level transaction like this :
_gaq.push(['_addItem',
'1234', // transaction ID - required
'DD44', // SKU/code - required
'T-Shirt', // product name
'Green Medium', // category or variation
'11.99', // unit price - required
'1' // quantity - required
]);
For the last step in the process, I send transaction data to my merchant processing (paypal) via the SOAP api and get numerous responses back. I do different stuff based on the response I get back. If there is no error from the JSON response I get an COMPLETED response, at that point is when I fire the :
_gaq.push(['_trackTrans']);
I'm not really sure if this is the true way to go about it, but it makes sense to me.

Easiest way to sell stuff and track inventory

on my website I sell unique items. I have programmed it so that on the selling page, users can select any amount of these items, and it calculates the cost. The key is that I only have 1 of each of these items. So I need the shopping cart system to not allow the payment to go through unless it is available.
I've been searching for a good quick/easy/cheap solution and can't find one. I don't expect this site to make a lot of money (the transactions are a few bucks), so I didn't want to need a ssl certificate.
The only way I know of not needing an ssl certificate would be to use paypal or google checkout. However, I do not think there is a way of using these services and making paypal's server run a script to check how many are available on the site. Any solution?
Thanks
I was thinking about it more, and I think the problem is that once the user gets to the paypal payment screen, I have no control. I guess I could do something like they click the buy it now link, a php script updates it to sold, then they go to the paypal screen, but then they might not continue the purchase...
If you use PayPal Website Payments Standard (using a cart rather than 'Buy Now' Buttons) then you could use IPN or PDT (see the paypal docs here) to get PayPal to call back to you with the status of the payment.
The work flow would then be to set status to reserved when the item is added to the cart, and then wait for the IPN/PDT call to come back with the payment status, and mark the item as sold.
You would still need to check and reset to available any item that had been reserved for longer than say 2 Hours. (You could do this before serving a page to a user so that they have the latest availability and you don't need a cron job or long running process)
If you could provide a little more information about how you have implemented ur shopping card, it would have been more easier for other to assist! If you are using any ecommerce solution then it should be there already in the track inventory section. But Provided that you have implemented d shopping cart manually, why don't you add little bit of codes that checks the inventory status first before letting your customers check out?

Web store: will customers come back to re-place orders?

Recently a bug in our web store caused the prices to be doubled at checkout. This lead to a drop in orders from about 25 to 2 over a period of 19 hours. We have lost quite some money over this. What I wonder is: is there any way to measure how many of those "dropped" customers will come back and re-place their orders?
If they logged in, their user details. If not, compare IP addresses from your server log, IPs which left without buying during the price doubling, to IPs in the next week, to get a rough idea.
I would say if your product is good your customers will come back. I would say now is a good time to start collecting some analytics on your site. You won't have much to compare to but it would be a place to start. To tell if your customers are coming back you could compare the purchase data from before the issue to after. I would think you'd have some type of userid they would have to either log in with or enter when purchasing. Our sites all require a username to login, we also offer a guest checkout which is just an email address but we could comparisons if we needed to.
A non-programming solution is to offer customers who had the problem some kind of discount or additional product if they finalise their order. This doesn't help you find out how many come back because you are changing the rules, but it will help you lose some of the lost money.
If you have a mailing list, mail out the special offer, else put it up on your website somewhere.
Ask them to fill in the details of the order again, if it matches a previous order in that time period offer them the special deal.