Payment is a generic payment platform which allows other modules to use any of the payment methods that plug into Payment. With Payment we only need one one Paypal, one credit card and one iDEAL module to use with every single webshop or payment form that you want (applies to any payment method that works with Payment). This shortens development time and improves support, because only one instead of three Paypal modules need to be maintained, and simplifies UX, because all payment (method) information is now located in one place.

For more information

• try the demonstration site.
• read the Payment handbook.
• follow the development of version 2 and read the change records.
• watch the Payment 8.x-2.x session recordings from DrupalCamp Ghent 2014.

Project contents

Note on PCI-DSS compliance

This input filter inserts even and odd classes into user submitted tables within nodes. This allows for proper table theming ("zebra stripes") to occur while allowing users to use regular table tags or a WYSIWYG editor to create tables.

To use this module, download, enable, and add to your input formats. Depending on the theme, CSS for the even and odd classes might need to be added. For more information, see the included README.

This module can be used by other modules to collect and track payments. Through this API, any module can provide a payment form and payments can be handled and tracked centrally.

Payment forms

A payment form is the result of any business rules that include a request or recommendation of payment. Examples include shopping cart checkout pages, donation forms, event registration pages, user registration forms, or tip jars.

A module using this payment API can be very simple or very complex, implementing any amount of business rules that result in a payment request. From there, Pay collects payment information and submits it through a configured payment backend. All payment activities, no matter what they're for, are stored in one place for tracking and reporting purposes.

Modules that implement payment forms include:

• Donate, which can be downloaded here.
• Webform Pay, which adds a Webform component to collect payments.

If you develop a new payment form module, please let us know so that we can add it to this list.

Payment backends

A payment form can support one or more payment methods, using the functionality of a payment method handler. Support for the following backends are available for Pay:

This is an Ubercart payment gateway module for the Stripe payment processor.

On a properly configured site and server with https configured, Ubercart with uc_stripe 7.x-2.x and 8.x-2.x should be PCI SAQ-A compliant since no credit card information passes through your server at all. Further discussion and details are in this issue

Adds a table display type to Views which prints fields out in a pure CSS table.

Why use this?

Views default table display style is packed with features such as column sorting, alignment and separators however the HTML table tag is notoriously difficult to override and style. Using CSS Tables (see http://caniuse.com/#feat=css-table for support) you can create views tables that work well on both mobile and desktop with minimal overrides.

webform_paymethod_select allows you to make payments part of your webforms. It makes embedding payment into your forms (nearly) as easy as adding a new textarea.

Aiming at some stripe (https://stripe.com/) integration. All are welcome to help out.

This currently is very basic. There's a simple form for testing purposes, that will charge a card. This is not ready for production environments

Webform Stripe adds super simple Stripe integration to Webforms, so that submissions can be "purchased".

With this, you can use webforms for event registrations, online donations, or even for simple products where you need to gather additional information from a user. Each webform can have fixed pricing, or it can be determined dynamically from another field component on the form.

Summary

Views Blocksit style plugin. Create dynamic grid layouts using the Blocksit JS jQuery plugin and Views. This module supports setting up breakpoints to change the number of columns as required. Blocksit JS provides a cascading grid layout, similar to that of the Masonry JS library and can be used as an alternative in many cases.

A demo of the library is available here.

Description :

The hide group module is used if you want to simplify the node forms by hiding fieldset, either by just not displaying them (display:none) or striping them from the form generation
Pretty usefull if you want to hide fieldset and keep the form element values

Installation instructions :

1. Download and uncompressed the archive into your site modules directory
2. Install the module (package User interface)

Usage :

There are 3 ways to hide a group :

This module provides a simple abstraction of the Stripe PHP SDK. It does not (and will not) provide any additional functionality. This module is designed to be required by other contrib/custom modules.

You must download the Stripe PHP library from GitHub.

This module provides a simple solution for role based subscriptions without requiring a fully featured ecommerce suite running on Drupal. It directly integration with Stripe's subscription architecture.

It is under active development and should not be used in a production environment yet.

Features

• Add/Remove roles based on subscription status
• Optionally require subscription purchase at registration
• Email templates for subscription and payment events
• Optional upcoming payment notifications
• Subscribers can easily update active card, subscription, and cancel
• Stripe events are integrated into Drupal’s hook system
• Plan Groups which allow for offering a subset of plan options based on context

Dependencies

• Stripe (Required)
• Secure Pages (Recommended unless full site is secure)
• Context (Optional for Plan Group reactions)
• Profile2 Registration Path (Optional for Plan Group registration paths)

Getting Started

A payment-method for Stripe.

Status / Limitations

Currently only credit-card payments are implemented. The transactions are made via JavaScript so your server never sees the credit card data therefore no PCI compliance is needed Stripe has you covered regarding PCI compliance if you serve your page via SSL.

MoneySuite provides a set of modules for Drupal sites that rely on the sale of memberships and/or content for revenue. This project is differentiated from the existing commerce modules in that it requires no special adaptation for the sale of memberships and handles one time or recurring payments through a variety of payment gateways.

Included in this release:

Setting up a paid membership feature on your website can bring your budding site to a grinding halt. We have years of experience with creating paid membership websites, so we know how complicated it can be. We're breaking that trend.

With Membersify, we have stripped out as much of the complexity as possible to give you a truly turn-key solution to getting your content monetized. What used to take weeks or months now can be done in hours or even minutes.

Provides the Stripe payment gateway for Commerce inside of a DrupalGap mobile application.

Provides a field formatter to format an integer field into a simple Stripe Checkout payment button, following the docs at https://stripe.com/docs/checkout.

It has a callback that will set the field to 0¢ when the payment is successful. For this reason we often call the field "Balance due" and we render the display price using a separate field.

Stripe Payment Processor integration for CiviCRM

Instructions

You do not need this module for CiviCRM 4.2+

There are no special steps required in Drupal.
Turn this module on and follow the steps required on CiviCRM's side.

Installing Stripe as a payment processor in CiviCRM 4.x:

The Field CSS module provides a field (which can then be added to any entity type) that accepts css, does minimal processing and then adds the css to the entity display.

It provides options to namespace any of the css declarations.

It provides two widgets, one that allows for structured entering of the CSS with the selector and the style in different fields, and a free form widget where all of the css can be entered in one large text area.

This module allows you to use variables to switch payment method settings.

How it works

You should use this module if you want to easily switch payment method settings between your test and production account.

Since those settings are stored in the database as a Rule, this module will check if a configuration is defined on your settings.php or settings.local.php and override the configuration.

IMPORTANT: The Give Record module is functionally required, you MUST enable it; top to-do is to combine into one module.

This module gives potential donors a couple easy ways to give to an organization or person:

• By credit card with Stripe (2.9% + 30 cents a transaction)
• (coming!) By bank transfer with Dwolla (no transaction fees)
• Pledge to pay by check

Other ways may get in there, but the focus will remain simplicity and flexibility for givers to donate in the lowest cost way (for the receiver) that they are willing to use.

This module concept is simple, small and specific.

It extends the concept of zebra striping, which allows odd/even alternation of styles to be applied to lists or table rows.

The Rainbow module will insert classes to allow cyclic styling of lists or table rows.

This is simple in principle, but requires experimentation to determine how to control which lists and tables it's applied to and what the size of the cycle will be in each case, e.g. a 3-colour cycle or a 7-colour full rainbow!

Feature suggestions welcome.

The purpose of this module is to provide a simple way for non-tech-saavy users to easily process content in commonly needed ways, including:

• Preprocessing Blocks
  • Adding first and last classes
  • Adding the block's source module and delta as classes
  • Adding simple 'configure,' 'edit block,' and 'edit menu' buttons on block hover
  • Integrating with common block modules, such as: Menu Block, Nice Menus, Menu Admin Per Menu, Skinr, etc.
• Preprocessing Pages
  • Adding classes to reflect front page, is_admin, content type, node id, etc.
  • Adding classes based on URL arguments
  • Adding classes for current user's role
  • Adding classes based on current user's browser client
  • Adding classes based on current page's taxonomy terms
  • Adding new template suggestions for content types like Panels (considering a separate ui for adding new suggestions)
• Preprocessing nodes
  • Adding classes based on node variables such as published, sticky, teaser, ownership
  • Adding classes based on current user's access to current node. E.g., user-node-update, user-node-delete, etc.
• Preprocessing Comments

Somewhat based on the Matrix module. Taxonomy Matrix is a bridge between taxonomy and a CCK Matrix field. It can be used to create a matrix of selections based on 2 selected taxonomy categories.

Using CCK, add a new Taxonomy Matrix field. The admin interface will ask you for the category to use for row headers, and the category to use for column headers.

Colors & Patterns would give you something like this: