Table Of Contents


You can obtain free community support for example through stackoverflow, or also through the Symfony2 mailing list.

If you think you found a bug, please create a ticket in the bug tracker.

Continuous Inspections

If you take code quality seriously, try out the new continuous inspection service.


The Model


Before we are going to see how we can conduct payments, let me give you a quick overlook over the model classes, and their purpose.


A PaymentInstruction is the first object that you need to create. It contains information such as the total amount, the payment method, the currency, and any data that is necessary for the payment method, for example credit card information.

Tip: Any payment related data may be automatically encrypted if you request this.

Below you find the different states that a PaymentInstruction can go through:

PaymentInstruction State Flow


Each PaymentInstruction may be splitted up into several payments. A Payment always holds an amount, and the current state of the work-flow, such as initiated, approved, deposited, etc.

This allows you for example to request a fraction of the total amount to be deposited before an order ships, and the rest afterwards.

Below, you find the different states that a Payment can go through:

Payment State Flow


Each Payment may have several transactions. Each FinancialTransaction represents a specific interaction with the payment backend. In the case of a credit card payment, this could for example be an authorization transaction.

Note: There may only ever be one open transaction for each PaymentInstruction at a time. This is enforced, and guaranteed.

Below, you find the different states that a FinancialTransaction can go through:

Financial Transaction State Flow