CRM_Core_Payment

Set back office property.

Get payment instrument id.

Getter for the id.

Set payment Instrument id.

By default we actually ignore the form value. The manual processor takes it more seriously.

Set base return path (offsite processors).

This is only useful with an internal civicrm form.

Set success return URL (offsite processors).

This overrides $baseReturnUrl

Set cancel return URL (offsite processors).

This overrides $baseReturnUrl

Set the configured payment profile.

Opportunity for the payment processor to override the entire form build.

Log payment notification message to forensic system log.

Check if capability is supported.

Capabilities have a one to one relationship with capability-related functions on this class.

Payment processor classes should over-ride the capability-specific function rather than this one.

Are back office payments supported.

e.g paypal standard won't permit you to enter a credit card associated with someone else's login. The intention is to support off-site (other than paypal) & direct debit but that is not all working yet so to reach a 'stable' point we disable.

Can more than one transaction be processed at once?

In general processors that process payment by server to server communication support this while others do not.

In future we are likely to hit an issue where this depends on whether a token already exists.

Are live payments supported - e.g dummy doesn't support this.

Are test payments supported.

Does this payment processor support refund?

Should the first payment date be configurable when setting up back office recurring payments.

We set this to false for historical consistency but in fact most new processors use tokens for recurring and can support this

Does this processor support cancelling recurring contributions through code.

If the processor returns true it must be possible to take action from within CiviCRM that will result in no further payments being processed. In the case of token processors (e.g IATS, eWay) updating the contribution_recur table is probably sufficient.

Does this processor support pre-approval.

This would generally look like a redirect to enter credentials which can then be used in a later payment call.

Currently Paypal express supports this, with a redirect to paypal after the 'Main' form is submitted in the contribution page. This token can then be processed at the confirm phase. Although this flow 'looks' like the 'notify' flow a key difference is that in the notify flow they don't have to return but in this flow they do.

Does this processor support updating billing info for recurring contributions through code.

If the processor returns true then it must be possible to update billing info from within CiviCRM that will be updated at the payment processor.

Can recurring contributions be set against pledges.

In practice all processors that use the baseIPN function to finish transactions or call the completetransaction api support this by looking up previous contributions in the series and, if there is a prior contribution against a pledge, and the pledge is not complete, adding the new payment to the pledge.

However, only enabling for processors it has been tested against.

Function to action pre-approval if supported

Get any details that may be available to the payment processor due to an approval process having happened.

In some cases the browser is redirected to enter details on a processor site. Some details may be available as a result.

Default payment instrument validation.

Implement the usual Luhn algorithm via a static function in the CRM_Core_Payment_Form if it's a credit card Not a static function, because I need to check for payment_type.

Getter for the payment processor.

The payment processor array is based on the civicrm_payment_processor table entry.

Setter for the payment processor.

Setter for the payment form that wants to use the processor.

Getter for payment form that is using the processor.

Get help text information (help, description, etc.) about this payment, to display to the user.

Getter for accessing member vars.

Get name for the payment information type.

Get label for the payment information type.

Get array of fields that should be displayed on the payment form.

Common results are array('credit_card_type', 'credit_card_number', 'cvv2', 'credit_card_exp_date') or array('account_holder', 'bank_account_number', 'bank_identification_number', 'bank_name') or array()

Get an array of the fields that can be edited on the recurring contribution.

Some payment processors support editing the amount and other scheduling details of recurring payments, especially those which use tokens. Others are fixed. This function allows the processor to return an array of the fields that can be updated from the contribution recur edit screen.

The fields are likely to be a subset of these - 'amount', - 'installments', - 'frequency_interval', - 'frequency_unit', - 'cycle_day', - 'next_sched_contribution_date', - 'end_date', - 'failure_retry_day',

The form does not restrict which fields from the contribution_recur table can be added (although if the html_type metadata is not defined in the xml for the field it will cause an error.

Open question - would it make sense to return membership_id in this - which is sometimes editable and is on that form (UpdateSubscription).

Get the help text to present on the recurring update page.

This should reflect what can or cannot be edited.

Get the metadata for all required fields.

Get the metadata of all the fields configured for this processor.

Get array of fields that should be displayed on the payment form for credit cards.

Get array of fields that should be displayed on the payment form for direct debits.

Return an array of all the details about the fields potentially required for payment fields.

Only those determined by getPaymentFormFields will actually be assigned to the form

Get billing fields required for this processor.

We apply the existing default of returning fields only for payment processor type 1. Processors can override to alter.

Get form metadata for billing address fields.

Get base url dependent on component.

(or preferably set it using the setter function).

Get the currency for the transaction.

Handle any inconsistency about how it is passed in here.

Get the currency for the transaction.

Handle any inconsistency about how it is passed in here.

Get url to return to after cancelled or failed transaction.

Get URL to return the browser to on success.

Get URL to return the browser to on failure.

Get URl for when the back button is pressed.

Get the notify (aka ipn, web hook or silent post) url.

If there is no '.' in it we assume that we are dealing with localhost or similar and it is unreachable from the web & hence invalid.

Calling this from outside the payment subsystem is deprecated - use doPayment.

Process payment - this function wraps around both doTransferCheckout and doDirectPayment.

Any processor that still implements the deprecated doTransferCheckout() or doDirectPayment() should be updated to use doPayment().

This function adds some historical defaults ie. the assumption that if a 'doDirectPayment' processors comes back it completed the transaction & in fact doTransferCheckout would not traditionally come back. Payment processors should throw exceptions and not return Error objects as they may have done with the old functions.

Payment processors should set payment_status_id (which is really contribution_status_id) in the returned array. The default is assumed to be Pending. In some cases the IPN will set the payment to "Completed" some time later.

Refunds payment

Payment processors should set payment_status_id if it set the status to Refunded in case the transaction is successful

Query payment processor for details about a transaction.

This function checks to see if we have the right config values.

Redirect for paypal.

Handle incoming payment notification.

IPNs, also called silent posts are notifications of payment outcomes or activity on an external site.

Payment callback handler.

The processor_name or processor_id is passed in. Note that processor_id is more reliable as one site may have more than one instance of a processor & ideally the processor will be validating the results Load requested payment processor and call that processor's handle<$method> method

Check whether a method is present ( & supported ) by the payment processor object.

Some processors replace the form submit button with their own.

Returning false here will leave the button off front end forms.

At this stage there is zero cross-over between back-office processors and processors that suppress the submit.

Checks to see if invoice_id already exists in db.

It's arguable if this belongs in the payment subsystem at all but since several processors implement it it is better to standardise to being here.

Get url for users to manage this recurring contribution for this processor.

Get description of payment to pass to processor.

This is often what people see in the interface so we want to get as much unique information in as possible within the field length (& presumably the early part of the field)

People seeing these can be assumed to be advanced users so quantity of information probably trumps having field names to clarify

Checks if backoffice recurring edit is allowed

Does this processor support changing the amount for recurring contributions through code.

If the processor returns true then it must be possible to update the amount from within CiviCRM that will be updated at the payment processor.

Checks if payment processor supports recurring contributions

Checks if payment processor supports an account login URL TODO: This is checked by self::subscriptionURL but is only used if no entityID is found.

TODO: It is implemented by AuthorizeNET, any others?

Should a receipt be sent out for a pending payment.

e.g for traditional pay later & ones with a delayed settlement a pending receipt makes sense.