Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Manual payment scheduling per Batch via Developer Console

 

Manual Payment

...

Scheduling

 

Step 0: Delete the existing payment schedule named “ASPP__ProcessingPayment” beforehand. To check, go to → Setup | Schedule Jobs  Jobs

 Step 1: From your user menu, click the Setup Gear icon and select Developer Console. 

 

  

Step 2: From your developer console, click Debug in the menu and select Open Execute Anonymous Window. 

Step 3: A pop-up Enter Apex Code windowwill appear.  

A. Copy the script (below) and paste in to Enter Apex Code window. 
 

String schedule_time = '0 0 2 * * ? *';   

...

Note: This is just a sample scheduling every 2AM. See other payment processing schedules below - “Other Payment Processing Schedules section” 
 

B. Click “Execute” button.  

...

Step 4: Confirm the created schedule in the Scheduled Jobs. Go to Setup | Schedule Jobs | 

 

 

Other Payment Processing Schedules 

 

A. Sample time schedules 

Change the value of the schedule_time variable to any preferred time schedule. 

·                Every hour = '0 0 * * * ?' ; 

·                Every midnight = '0 0 0 * * ?' ; 

·                Every 1 AM = ’0 0 1 * * ? * ‘ ;  

·                Every 2 AM = ’0 0 2 * * ? * ‘ ;  

·                Every 3 AM = ’0 0 3 * * ? * ‘ ;   
 

B. Time Schedule Formats 

...

optional_year: null or 1970–2099 , - * / 

 

 

ProntoPayments

...

Batches

Go to | ProntoPayments Settings | Scheduler 

Parse Payment From ASPP_Logs (No) 

A chained process from Batch Payment Processing so this will be called internally every batch payment processing attempt.  

Batch Payment Processing (Yes) - Schedule for 9pm 

Default schedule is 9PM. 

 

Batch Get Payment Status (Yes) - Schedule for 9am 

This is for Ezidebit, Westpac and Paydock transactions only. This will update the statuses of those pending transactions based on the gateway response and opportunity stages. 

 

Batch Attach ProntoPayments Logs (Yes) - Schedule for 9pm 

This will create a backup for old ASPP Logs so that when Batch Delete ProntoPayments Logs is scheduled, we can still those records as csv file. 

 

Batch Send Email for Expired Cards (OPTIONAL - client preference) - Consider deprecation - replace with subscribing to report  

This will send an email notification to the running user. The email contains a list of payment sources records. Default schedule is 11PM.  

Batch Get Payments (OPTIONAL - client preference) 

...

  1. Paydock 

  2. Ezidebit 

  3. eWAy 

  4. Paypal Rest 

  5. PIN 

  6. Stripe 

  7. DebitSuccess 

...

Batch Get Tokens (OPTIONAL - client preference) 

Sync tokens (as payment sources) from gateway to salesforce.  

Batch Inactive Expired Payment Source (OPTIONAL - client preference) 

All expired payment sources, both tokenisation-credit card and credit card, will be updated to inactive ONLY if expiry date is not empty. 

 

Batch Get Subscriptions (OPTIONAL - client preference) 

Sync subscriptions from gateway to salesforce.  

Batch Create Subscription PPayment (OPTIONAL - client preference) 

Will retrieve transactions from the gateway only if subscription is processed on the gateway (not on salesforce). 

 

Batch Payment Status Update (No) 

A chained process from Batch Payment Processing so this will be called internally every batch payment processing attempt.  

Sandbox Clean up Batch (No) 

...

This batch will update transactions where gateway is either BPOINT or Ezidebit. This will retrieve settlement dates from the gateway (when available).

 

 

See over for the batch tables.

Batches

Batch Class Name

Descriptions

Default Scheduled Hour

Set To Scheduled 

Batch Payment Processing

ASPP_AuthBatch

 

·               

Every 12midnight

TRUE

Batch EziDebit Get Payment Status

BatchGetPaymentsStatusEziDebit

·               

This is for Ezidebit transactions only. This will update the statuses of those pending transactions based on the gateway response and opportunity stages.

·               

Default scheduled every 6am

TRUE

Batch Attach ProntoPayments Logs

ASPP__ProcessingOpportunityAttachPPLogs

·               

This will create a backup for old ASPP Logs so that when Batch Delete ProntoPayments Logs is scheduled, we can still those records as csv file.

·               

Default scheduled every 8pm

 

Batch Delete Temporary Payment Source

ASPP__ProcessingBatchDeleteTemporaryPS

 

·               

Default scheduled every 8pm

 

Batch Send Email for Expired Cards

ASPP__BatchExpiredCardsEmailNotification

·               

This will send an email notification to the running user. The email contains a list of payment sources records.

·               

(OPTIONAL - client preference) - Consider deprecation - replace with subscribing to report

 

 

Batch Get Payments

ASPP__BatchGetPayments

·               

Sync payments from gateway to salesforce. Below are the supported gateways.

·               

(OPTIONAL - client preference)

Paydock

Ezidebit

eWAy

Paypal Rest

PIN

Stripe

DebitSuccess

 

TRUE

Batch Get Tokens

ASPP__BatchGetTokens

·               

Sync tokens (as payment sources) from gateway to salesforce.

·               

(OPTIONAL - client preference)

 

TRUE

Batch Inactive Expired Payment Source

ASPP__BatchInactiveExpiredPaymentSource

·               

All expired payment sources, both tokenisation-credit card and credit card, will be updated to inactive ONLY if expiry date is not empty.

·               

(OPTIONAL - client preference)

 

 

Batch Delete ProntoPayments Logs

ASPP__BatchProcessedPayment__DeleteLogs

·               

(OPTIONAL - client preference)

 

 

Batch Get Subscriptions

ASPP__BatchGetSubscriptions

·               

Sync subscriptions from gateway to salesforce.

·               

(OPTIONAL - client preference)

 

TRUE

Batch Create Subscription PPayment

ASPP__BatchCreateSubscriptionPPayment

·               

Will retrieve transactions from the gateway only if subscription is processed on the gateway (not on salesforce).

·               

(OPTIONAL - client preference)

 

TRUE

Batch Payment Status Update

 

 

 

FALSE - No need to run the batch as it is already included in Payment Processing chain.

Get Payment Transaction Settlement

UpdateSettlementDateBatch

·               

This batch will update transactions where gateway is either BPOINT or Ezidebit. This will retrieve settlement dates from the gateway (when available)

·               

Scheduled every 6am

TRUE

Batch Generate CRN for Contact

GenerateCRNforContactBatch

·               

Necessary when Ezidebit BPAY is used.

·               

Scheduled every 7pm

FALSE - pending functionality

...

ProntoGiving 

Go to ProntoGiving Settings | Schedule Process | Settings 

BDE Item processing will only process standard objects; custom objects are not supported.

ProntoGiving - Other Batches 

...

Description: 

·                ASPHPPADDON__Donation_Page_Error_Log__c records are created if errors are encountered in Donation Page/Forms i.e. Contact, Account or Payment Source could not be created due to validations errors 

·                Opportunity/RD records needs to be created in SF even if some records could not be created to capture the donation attempt and take action to complete the donation process 

...

Process BDE Items - Yes - 6pm?. Setting should Exclude items linked to BDE 

Query Criteria: 

· All ASPHPPADDON__BDE_Item__c with ASPHPPADDON__Processing_Status__c = ‘Pending Processing’ 

· If PRONTOGIVING_SETTINGS.Include_BDE_Items_linked_to_a_BDE__c is TRUE, all BDE Items 

· If PRONTOGIVING_SETTINGS.Include_BDE_Items_linked_to_a_BDE__c is FALSE, exclude BDE Items linked to a Batch Donation Entry 

What the batch does, for all retrieved ASPHPPADDON__BDE_Item__c records: Process these records, just like processing BDE Items via list view view.  

Batches

Batch Class Name

Descriptions

Default Scheduled Hour

 

Delete Donation Page Error Logs

ASPHPPADDON__Donation_Page_Error_Log__c

·               

Donation Page Error Logs records are created if errors are encountered in Donation Page/Forms.

·               

All Donation Page Error_Logs with lookup to Opportunities that are Closed/Won with CreatedDate <LAST_N_DAYS> (settings) It remove records because they’re no longer significant.

 

TRUE

Delete Bulk Donation Logs

 

 

 

FALSE - Not in use object

Process BDE Items

ASPHPPADDON__BDE_Item__c

·               

Processing BDE Items via list view

·               

Query all BDE Items with Processing Status “Pending Processing” and process these records

Every 6pm

TRUE

...

Recurring Donations – ProntoGiving

...

Recurring Donations Monitoring  

Batch Class Name: BatchUpdateRecurringFields 

...

  • First Donation Date - Close Date of the first Closed Won opportunity 

 
 

Update Number Of Failed Recurring Donations 

Batch Class Name: BatchUpdateNumberOfFailedRD 

...

· If Open-Ended Status is Closed, Exclude_in_Updating_Number_of_Failed_Rec__c is set to TRUE TRUE

 
 

Close Open Recurring Donations with Contact Flagged as Deceased 

Batch Class Name: BatchCloseOpenRDWithDeceasedContact 

...

· Open-Ended Status = Closed 

· Status = Cancelled  Cancelled 

Total Recurring Donations - Last Financial Year 

Accessible in: 

· ProntoGiving Settings > Consolidated Statement Settings > Calculate Recurring Donations in the Last Financial Year 

...

· Account record: Total_Recurring_Gifts_Last_FY__c (amount)  
 

Lock/Unlock Recurring Donations Payment Processing

...

Accessible in: 

· ProntoGiving Settings > Recurring Donation Settings > Lock Recurring Donations Payment Processing (toggle) 

...

o  set log record on the opportunity as ASPHPP__Lock_Opportunity__c → FALSE  
 

Number of Fails before Cancelling Recurring

...

Donation

 

· Based on “Number of Failed Recurring Donations” field on RD record, if the field matches the set limit in ProntoGiving Settings, RD Status is updated to “Cancelled”, thus Open-Ended Status is updated to “Closed”  “Closed”
 

Batch Re-active RDs (not RD Monitoring Batch) -> 

WHERE Status__c =: RD_STATUS_PAUSE AND npe03__Next_Payment_Date__c = LAST_N_DAYS   

LAST_N_DAYS -> 30 days  days

IE: updates donation back to active 30 days prior to next donation date. 

Batches

Batch Class Name

Descriptions

Default Scheduled Hour

 

Recurring Donations Monitoring

BatchUpdateRecurringFields

 

Every Hour

 

Update Paused Donations due to Restart

 

 

 

TRUE

Update Number Of Failed Recurring Donations

Number of Fails before Cancelling Recurring Donation

BatchUpdateNumberOfFailedRD

·                Query all non-closed RDs and counts the number of (latest) consecutive closed lost opportunities.

·                Based on “Number of Failed Recurring Donations” field on RD record, if the field matches the set limit in ProntoGiving Settings, RD Status is updated to “Cancelled”, thus Open-Ended Status is updated to “Closed”

Every Midnight

TRUE

Close Open Recurring Donations with Contact Flagged as Deceased

BatchCloseOpenRDWithDeceasedContact

·                Query all non-closed RDs with Contact npsp__Deceased__c == TRUE 

·                Open-Ended Status = Closed

·                Status = Cancelled

Every Midnight

TRUE

 

...

ProntoPlus

Go to ProntoPlus Settings | Schedule Processes

Batches

Batch Class Name

Descriptions

Default Scheduled Hour

Set To Scheduled 

Send Receipts 

RCT__BatchSendReceipts

·                Query all Opportunities with Receipt Action Default and update to Email or Post. From Opportunities with receipt action Email it generate receipts of the opportunity without the Last Receipt populated.

·                BDE Receipt Action Email it will be receipted every 10mins

Every 10 mins

TRUE

Generate Receipts

RCT__BatchGenerateReceipt

List view from the Opportunity level without the Last Receipt populated for Post.

 

TRUE - if the PPL version is 2.57 or higher. 

FALSE - if the PPL version 2.56 or below