Paypal Payment Buttons with Meteor

July 30, 2014 Leave a comment

Recently I began investigating how one would use Paypal’s Payment buttons ( with Meteor. Since I wrote the Paypal Meteor package ( I figured I would address this question. Contrary to what you would believe, to use Meteor with this payment option, you do not need to add the meteor-paypal package. Here are the steps required to get the buttons working with your meteor application.


Setup your Paypal Developer

This can be done on You will need this sandbox account to test that your button is working correctly. This information will be used to create the button.

Setup the Button Itself

Follow the instructions on the page at: to set up the button and for testing purposes change the callback url to something like http://localhost:3000/paypalCallback. This will be used on your development machine to verify the callback is being hit. You will need to change this when you deploy your application to your production URL.

Add a Route To Your Application

Using a plugin such as IronRouter set up a route. For our example here we will use paypallCallback as our callback route. That means locally you can address our callback route with http://localhost:3000/paypalCallback and on a production system it would be

In the router, I have setup the code: {

this.route(‘/paypalCallback’, {

where: ‘server’,

action: function() {‘callBackendCode’, this.params, function(err, res) {

console.log(‘got the response’);





Add a Meteor Method

In the server directory create a js file to hold the server call. I named mine paypal_secret.js. Inside this file I created the Meteor method I’m going to be calling:


callBackendCode: function(params) {

console.log(‘you sent up the parameters’ + params);

//here you will do all your paypal tracking. The params should have information regarding the customer.



Add the Form to the Page

This is where you need to customize the form to fit the element you’re looking to sell. Copy the following form into your template and replace the values in blue:

<form method=”post” action=”; class=”paypal-button” target=”_top” style=”opacity: 1;”>

    <div class=”hide” id=”errorBox”></div>

    <input type=”hidden” name=”button” value=”buynow”>

    <input type=”hidden” name=”business” value=”YOUR EMAIL“>

    <input type=”hidden” name=”item_name” value=”ITEM NAME“>

    <input type=”hidden” name=”quantity” value=”THE QUANTITY“>

    <input type=”hidden” name=”amount” value=”THE PRICE“>

    <input type=”hidden” name=”currency_code” value=”THE CURRENCY (usually set to ‘USD’)“>

    <input type=”hidden” name=”shipping” value=”THE SHIPPING COST“>

    <input type=”hidden” name=”tax” value=”THE TAX AMOUNT“>

    <input type=”hidden” name=”notify_url” value=”http://localhost:3000/paypalCallback”&gt;

    <input type=”hidden” name=”env” value=”www.sandbox”>

    <input type=”hidden” name=”cmd” value=”_xclick”>

    <input type=”hidden” name=”bn” value=”JavaScriptButton_buynow”>

    <button type=”submit” class=”paypal-button large”>Buy Now</button>



For a reference you can Create & Preview a button and then inspect the code for the button to find the form it created.


Categories: Uncategorized

Meteor Template Naming Technique

December 13, 2013 Leave a comment

If you haven’t gotten to try out Meteor I would not waste another second and begin the tutorials immediately.

I am writing this from a position of having been doing Ruby on Rails professionally for several years and only having played with Meteor for a few small projects (Paypal Battlehack entry and Meteor Paypal). I have, however, run into some confusion when naming my Meteor templates. I initially followed the technique demonstrated in most of the documentation of using camelCase and something like my users index template would be named something like:

<template name=’usersIndex’>

and then referenced via:


This methodology, while great for initial pages can get a little hairy when you start using more and more of the “partial” mentality so prevailent in Rails. I really prefer this idea because I do believe in the DRY philosophy and I think any time I have to Copy/Paste code there is potential for a partial. It was through adding these partials that I would come up with names like:

<template name=’userProfileEditForm’>


<template name=’eventParticipantShowInformation’>

which I thought were incredibly hairy and did not give any sort of insight into where they could be found. I then realized that the malleability of Javascript could really come in handy here. I began renaming my templates to reflect their location such as:

<template name=’users/profile/form’>


<template name=’event/participant/information’>

where I would create directories mapping each of these names separated by the slashes. Unfortunately this does not allow us to continue to use the methodology so bedrock to the Meteor demonstrations because doing:


is not valid javascript. Here is where that malleability of Javascript comes into play. By changing the dot-notation to a hashmap notation we are easily able to access the template with:


this works in every instance and easily allows us to structure our meteor application keeping directories and file names small and consice. I also perfer this method as opposed to using snake_case because the slashes give a more directory-like feel and allow for people coming from rails to append the famous _ for partials such as: “_form

I know Meteor is still in it’s early stages and this type of dynamic naming could potentially become unavailable but it’s a solution to a headache that I had really enjoyed using. I am also extremely grateful for all the work the Meteor team has done to make such an incredible framework. I strongly recommend anyone who hasn’t read it read the book: Discover Meteor as it is incredibly useful.


Thanks for reading!

//davidbrear (@davidbrear04)

Categories: Javascript, Meteor, Programming

Rows Without Grouping

October 19, 2013 Leave a comment

Disclaimer: I am using bootstrap 3 for this webapplication so I will be referencing rows and columns as .row and .col-lg-# respectively.

Recently I started working on a feature for an application that required rows of elements with 4 elements per row. This was easy enough using Rails with the in_groups_of method and doing each grouping inside a .row. The problem came in when I wanted to allow these elements to be removed. I did not want to refresh the page but wanted the removed elemented to be taken out of the flow the page.

Enter CSS’s nth-child pseudo class. I was able to create a class called .row-4 and inside, added the following css:

.row.row-4 {

    .col-lg-3:nth-child(4n+1) { clear: left; }

    .col-lg-3:nth-child(4n) { clear: right; }


    I was then able to use jquery’s animate functionality to do: animate({‘width’: 0, ‘opacity’: 0}, function(){ $(this).remove(); }); to slide the element over  as it fades out and then remove it. While this caused a little bit of jumping, it was much more visually friendly than removing the element. and having everything jump.

    There is still a problem in that the text of the element, as it’s being smashed down horizontally begins to expand vertically. This, for a brief moment would cause the element below to be pushed way down then jump back when the element is removed. I solved this by using the styles: white-space: nowrap; and text-overflow: hidden because I only had a heading.

Categories: Uncategorized