Spreedly uses the xmldsig library to perform the signing.
To properly sign an xml request, enclose the entire xml request to be signed in xml_dsig template tags.
Do not modify the <wsse:Security> node. It must be formatted as given. This binary security token node will be generated on the server along with the timestamp.
Changes to the wsu:Id attribute of any node will cause signature failures.
Export multiple payment methods in a single, asynchronous, batch call to an SFTP receiver endpoint.
Because the Visa file format is quite unwieldy, and requires encryption, we'll approach this in two phases. First we'll work on getting a test file exported w/ test payment methods and no encryption so you can confirm that your file template is working. Then, we'll add the gpg encryption required by Visa and have it use the production receiver.
Export is part of Spreedly's PMD/receiver functionality, which allows you to send card data to non-gateway APIs. As such, export shares much of its terminology and functionality with deliver, the single-card and synchronous version of export.
First, create a test receiver that will let you specify any hostname (add the sftp auth in the protocol section):
| body { | |
| width: 800px; | |
| margin-right: auto; | |
| margin-left: auto; | |
| font-family: Helvetica, arial, sans-serif; | |
| font-size: 14px; | |
| line-height: 1.6; | |
| padding-top: 10px; |
When working with large, high volume, low latency systems, it is often the case that processing data sequentially becomes detrimental to the system's health. If we only allow 1 process to work on our data we run into several challenges:
For these reasons, we wish to design a system which allows N number of processes to work on a single data set. In order to arrive at a possible solution, let me outline some assumptions of the system.
Static sites are sites that don't contain any dynamic server-side functionality or application logic. Examples include brochure sites made up completely of HTML and CSS or even interactive client-side games built in Flash that don't interact with a server component. Though these sites only require a web-server to deliver their content to users it's still useful to use a platform like Heroku to quickly provision and deploy to such infrastructure.
Using the Rack framework, static sites can be quickly deployed to Heroku.
Source for this article's sample application is [available on GitHub](https://github.com/leereilly/static-site-heroku-cedar-example) and can be seen running at [http://frozen-hollows-6619.herokuapp.com/](http://frozen-
| # | |
| # This file configures the New Relic Agent. New Relic monitors | |
| # Ruby, Java, .NET, PHP, and Python applications with deep visibility and low overhead. | |
| # For more information, visit www.newrelic.com. | |
| # | |
| # Generated June 03, 2013 | |
| # | |
| # This configuration file is custom generated for Barsoom | |
Though slightly more complex, using a CDN is the most performant option for serving static assets. See the [CDN asset host](cdn-asset-host-rails31) article for more details.
Ruby on Rails applications should use Rack::Cache to efficiently serve assets on the Cedar stack. Proper Rack::Cache usage improves response time, decreases load and is important when serving static assets through your application.
This article will summarize the concepts of caching assets using Rack::Cache and walk you through the appropriate configuration of a Rails 3.1 application and the asset pipeline.
Sample code for this article's [reference application](https://github.com/heroku/rack-cache-demo) is available on