This documentation relates to CiviCRM version 3.2. It's not maintained anymore.
Current version of documentation.

Testing Processor Plugins

Skip to end of metadata
Go to start of metadata

This page refers to outdated version of CiviCRM. Check current version of documentation.


Documentation Search


CiviCRM 3.2 Documentation

Support and Participation

Developer Resources


CiviCRM book!

Make sure to check out Understanding CiviCRM as well! You can also support this project by ordering a hard copy.

CiviCRM Payment Processor Test Spec

Here's some suggestions of what you might test once you have written your payment processor plug in.

*** Don't forget that you need to search specifically for TEST transactions*************

ie from this page civicrm/contribute/search&reset=1 chose 'find test transactions

Std Payment processor tests

1) Can process Successful transaction from

            - Event

            - Contribute Form

            - Individual Contact Record

Transaction should show as confirmed in CiviCRM and on the payment processor

2) Can include , . & = ' " in address and name fields without problems. Overlong ZIP code is handled

3) Can process a failed transaction from a Contribute form

Can fix up details & resubmit for a successful transaction

e-mail address is successfully passed through to payment processor and payment processor sends e-mails if configured to do so.

The invoice ID is processed and maintained in an adequate manner

7) Any result references and transaction codes are stored in an adequate manner

Recurring Payment Processor tests

NB - IN Paypal Manager the recurring billing profiles are in Service Settings/Recurring Billing/ Manage Profiles

1) Process a recurring contribution. Check

            - wording on confirm page is acceptable

            - wording on thankyou pages is acceptable

             - wording on any confirmation e-mails is acceptable

           - the payment processor shows the original transaction is successful

            - the payment processor shows the correct date for the next transaction

            - the payment processor shows the correct total number of transactions and / or the correct final date

2) Try processing different types of frequencies. Preferably test a monthly contribution on the last day of a month where there isn't a similar day in the following month (e.g. 30 January)

3) Process a transaction without filling in the total number of transactions (there should be no end date set)

4) Process a recurring contribution with the total instalments set to 1 (it should be treated as a one-off rather than a rec urring transaction). It should not show 'recurring contribution' when you search for it in CiviCRM

5) PayflowPro - check that you can edit the frequencies available on the configure contribution page form

6) Depending on your processor it may be important to identify the transactions that need to be updated or checked. You may wish to check what it being recorded in the civicrm_contribution_recur table for payment processor id, end date and next transaction date.

Specific Live tests

1) Successful and unsuccessful REAL transactions work

2) Money vests into the bank account

3) For recurring transactions wait for the first recurrent transaction to vest

Labels
  • None

Creative Commons License
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-Share Alike 3.0 United States Licence.