CRM_Core_Payment_PayPalImpl

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.

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.

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.

This function collects all the information from a web/api form and invokes the relevant payment processor specific functions to perform the transaction

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

The function ensures an exception is thrown & moves some of this logic out of the form layer and makes the forms more agnostic.

Payment processors should set payment_status_id. 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.

doDirectPayment does not do an immediate payment for Authorize.net or Paypal so the default is assumed to be Pending.

Once this function is fully rolled out then it will be preferred for processors to throw exceptions than to return Error objects

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.

For paypal see : https://developer.paypal.com/webapps/developer/docs/classic/api/merchant/GetTransactionDetails_API_Operation_NVP/

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.

Paypal express replaces the submit button with it's own.

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.

Constructor.

Helper function to check which payment processor type is being used.

Billing mode button is basically synonymous with paypal express.

This is probably a good example of 'odds & sods' code we need to find a way for the payment processor to assign.

A tricky aspect is that the payment processor may need to set the order

Express checkout code.

Check PayPal documentation for more information

Get details from paypal.

Check PayPal documentation for more information

Do the express checkout at paypal.

Check PayPal documentation for more information

Create recurring payments.

Use a pre-authorisation token to activate a recurring payment profile https://developer.paypal.com/docs/classic/api/merchant/CreateRecurringPaymentsProfile_API_Operation_NVP/

Initialise.

Process incoming notification.

Hash_call: Function to perform the API call to PayPal using API signature.

This function will take NVPString and convert it to an Associative Array.

It will decode the response. It is useful to search for a particular key and displaying arrays.

Map the paypal params to CiviCRM params using a field map.

Is this being processed by payment express.

Either because it is payment express or because is pro with paypal express in use.