Contents

Member Sign in

admin

Recurring Payments -- Proposed Design

Billing Model

Sermons Online is a streaming media hosting service. A monthly fee is charged based on the amount of disk space used to store the customer's audio/video files.

Each month, the amount of disk space used by each customer is audited, and a charge is posted to Sermons Online's internal accounting system. Customers may pay for these charges either manually with a check, or automatically with a credit card (subscription billing).

Usage fees are calculated in units of 1 GB. 1 GB is typically enough for a year's worth of sermon audio files, so most customers' monthly fee amount will change approximately once a year. Customers may also set up rules to limit the amount of disk space used, and for these customers, their monthly fee amount will essentially never change.

Selecting and Authorizing a Payment Method

Sermons Online customers login to the Sermons Online Manager to select a manual or automatic payment method.

Manual Payments

Manual payments are authorized by sending an email to the customer's billing point of contact to verify that the email address is valid and that messages can be sent without being filtered. If the customer reads the email and clicks on a link contained within it, then the payment method is confirmed.

Automatic Payments

Automatic payments are authorized by asking the user to provide credit card information, then submitting a transaction to the Payment Gateway. For new accounts, an Authorization Only transaction is sent; for existing accounts, a Recurring Update transaction is sent. If the transaction is accepted by the Payment Gateway, then the payment method is confirmed. All credit card information is stored by the Payment Gateway, not on Sermons Online.

The use cases involed in selecting a payment method are as follows:

Select Payment Method Use Cases
1. Select Payment Method
  1. The use case begins when the Customer edits the Billing section of their Sermons Online profile. This section shows:
    • A drop-down list of available payment methods: "Manual -- Pay by Check", or "Automatic -- Pay by Credit Card".
    • If the current payment method is Automatic, a message showing the name and last 4 digits of the card currently being used..
    • A status message indicating whether the payment method has been confirmed.
    • A submit button for confirming a change in method
    • By default, the payment method is "Manual" and the confirmation status is "Unconfirmed".
  2. The Customer selects a payment method and then clicks on the submit button to confirm their choice. If confirming a manual payment, the Customer performs the Authorize Manual Payment use case. If confirming an automatic payment, the Customer performs the Authorize Automatic Payment use case.
2. Authorize Automatic Payment
  1. The use case begins when the Customer has chosen to make automatic payments and wants to confirm or update their credit card information.
  2. The system presents a form with the information required to establish a recurring billing with the Payment Gateway. When the user submits the form the following steps are taken:
    • If the customer's current payment method is "Manual", this is a new request to authorize payment, and an Authorize-Only transaction is sent to the Establish or Update Recurring Billing use case. The following data is used:
      • username/password: as defined in Sermons Online
      • item_sku: 200:001
      • item_desc: Sermon Hosting
      • item_type: SUB
      • bill_cycle: 1 month
      • recur_bill_amount: 1.00
      • num_cycles: 999
      • prorate_first_billing: 0
      • recur_bill_day: 2
    • If the Customer's current payment method is "Automatic", this is a request to update the card information, and a Recurring Update transaction is sent to the Establish or Update Recurring Billing use case.
  3. If the recurring transaction response returned by the Payment Gateway is "Approved":
    • The payment method is changed to "Automatic"
    • The confirmation status is set to "Confirmed"
    • The order id and transaction amount of the recurring transaction is saved to the customer's profile.
  4. If the response is "Declined" then:
    • If the error code indicates that the card information may have been mis-entered, the Sermons Online payment authorization form will be re-presented with the suspect fields highlighted for correction.
    • If the error code indicates that there is some mis-configuration between Sermons Online and the Payment Gateway, the Customer is presented with a notice that payment authorizations cannot be processed at this time, and an alert workflow will be opened to forward the error information to Sermons Online technical support.
2.1 Establish or Update Recurring Billing
  1. The use case begins when Sermons Online submits a Sale or Recurring Update transaction. The system processes the transaction request and responds with status information in text response format.
  2. If the transaction is for a Sale transaction and is approved, then the Payment Gateway also sends a receipt of the transaction to the Customer.
3. Authorize Manual Payment
  1. The use case begins when the Customer chosen to make manual payments, and wishes to confirm their billing contact information.
  2. The system presents a form with the information required to establish a manual payment. When the user submits the form the following steps are taken:
    • The system adds a workflow to do the Email Manual Payment Confirmation use case.
    • The system presents a message telling the Customer that an email has been sent to the billing point-of-contact.
3.1 Email Manual Payment Confirmation
  1. The use case begins when the workflow task to confirm a manual payment method has been triggered.
  2. The system sends an email addressed to the billing point of contact of the customer, then ends. The email contains a link which will perform the Confirm Manual Payment use case.
3.2 Confirm Manual Payment
  1. The use case begins when a Customer has clicked on a link in an email sent to confirm a manual payment. The link contains the customer id as a parameter.
  2. Upon receipt, the system validates that the passed customer's payment method is set to "Manual", and the current confirmation status is "Unconfirmed". If not, the system opens an alert workflow to Sermons Online billing, passing the request as a possible error, and the use case ends.
  3. The confirmation status is changed to "Confirmed"
  4. If the customer's profile in Sermons Online includes an order id, then the Cancel Recurring Billing use case is performed and the use case ends.
3.3 Cancel Recurring Billing
  1. The use case begins when Sermons Online submits a Subscription Lookup and Cancel Subscription transaction pair. The system processes the transaction request, removes its record of recurring billing, and the use case end.


Processing Monthly Payments

Processing of monthly payments is done by both Sermons Online and the Payment Gateway.

Sermons Online Processing

On the first day of the month, a software agent on Sermons Online performs an audit of the disk space usage. The monthly audit evaluates any disk-limit rules specified by the customer, calculates the amount of disk space being used, then posts charges.

For Manual payment customers, the software agent sends an email invoice to the billing point-of-contact. The customer follows the instructions in the email to write a check and mail it back to Sermons Online, where it is manually processed.

For Automatic payment customers, the software agent makes sure that the Payment Gateway's recurring billing system is properly configured to settle the total amount due when it runs on the following day.

Payment Gateway Processing

On the second day of the month, a sofware agent on the Payment Gateway performs a Recurring Sale transaction, and post-backs the transaction details to Sermons Online. Sermons Online uses the post-back information to automatically clear the customer's charges.

Errors encountered during monthly processing are escalated to the Sermons Online billing staff for resolution.

The use cases involved in processing monthly payments are as follows:

Monthly Billing Use Cases
1. Audit Usage and Post Charges
  1. The use case begins when the Usage Audit Agent performs its monthly processing of Sermons Online billing.
  2. The system calculates an invoice date as being the first day of the current month.
  3. The system selects all customers with a customer status of "Active" or "Evaluating", and for each customer, it performs the following steps:
    • If the customer status is "Evaluating", the system books a "free trial" transaction and the next customer is processed.
    • If an invoice has already been booked for the customer for the invoice date, the billing transaction is skipped and the next customer is processed.
    • The system removes all expired sermons (sermons in Inactive or Pending status for 1 month or longer) and their associated media files.
    • The system calculates the disk space used by the customer's sermon media files.
    • If the customer is not using any diskspace, or if the customer has a billing type of "nocharge", the billing transaction is skipped and the next customer is processed.
    • If the customer has enabled auto-deletion, the system changes the status of all auto-deletion candidates to "inactive", so they will be removed in next month's billing cycle.
  4. At this point in the flow, we have an active customer, with active content, who should be billed. The system books charges for the current month's usage into the Sermons Online accounting system, applying any discounts which may apply. The transaction will use the following data values:
    • item id: 200:001, "Sermons Hosting"
    • vendor id: 4, "Billing Agent"
    • date: invoice date
  5. If the customer's payment method is "Manual", then the system performs the Email Billing Statement use case and the next customer is processed.
  6. If the customer's payment method is "Automatic" and the total amount due is equal to the customer's recurring billing amount, then the next customer is processed.
  7. If the total amount due is not equal to the transaction amount stored in the customer's profile, the system sends an Update Recurring transaction request to the Payment Gateway to update the recurring billing amount to cover the amount due.
  8. If the transaction response returned by the Payment Gateway is "Approved", the new transaction amount is saved in the customer's profile, and the next customer is processed..
  9. If the response is "Declined" then the system adds an alert workflow to forward the failed transaction details to Sermons Online technical support and the next customer is processed.
  10. Once all customers have been processed, the use case ends..
1.1. Update Recurring Billing Amount
  1. The use case begins when Sermons Online submits a Recurring Update transaction. The system processes the transaction request, responds with status information in text response format, and the use case ends.
1.2. Email Billing Statement
  1. The use case begins when the workflow task to email a customer's billing statement has been triggered.
  2. The workflow system retrieves the customer's current charges from the Sermons Online accounting system, and sends an email notice to the billing point of contact.
  3. The use case ends.
2. Post Automatic Payment
  1. The use case begins when the Recurring Billing Software Agent performs its monthly processing of recurring billing for Sermons Online customers. All Sermons Online customers are configured to make payments on the second day of the month.
  2. For each Sermons Online customer, the system:
    • Retrieves the recurring billing details and credit card payment information.
    • Makes a Sale transaction on behalf of Sermons Online
    • If the transaction status is "Approved", the system performs the Email Automatic Payment Receipt use case.
    • Posts-back the result of the transaction to the Sermons Online Accept Automatic Payment use case. The report must include the following information: Sermons Online customer id, transaction identifier, transaction date, transaction amount, and a transaction status of "Approved" or "Declined".
  3. Once all Sermons Online customers have been processed, the use case ends.
2.1. Email Automatic Payment Receipt
  1. The use case begins when the Payment Gateway has made a sucessful recurring billing transaction using the Sermons Online customer's credit card.
  2. The system sends an email receipt to the Sermons Online customer's billing point of contact, and the use case ends.
2.2. Accept Automatic Payment
  1. The use case begins when the Payment Gateway posts a recurring billing payment for a Sermons Online customer.
  2. The system receives a recurring billing payment notice from the Payment Gateway. The payment notice will include the Sermons Online customer identifier, a payment amount, and a payment date.
  3. The Sermons Online system will calculate the invoice date as being the first day of the month in which the recurring payment was made.
  4. The Sermons Online system will select all accounting transactions that match the following criteria, and calculate the total amount.
    • item id = 200:01
    • vendor id = 4
    • date=invoice date
  5. If the total amount of the selected transactions is equal to the payment amount reported by the Payment Gateway, then the payment is used to clear the transactions, and the use case ends.
  6. If the total amount does not equal the payment amount, the system opens an alert workflow to forward the payment details to Sermons Online Billing, and the use case ends.
3. Mail Check to Sermons Online Billing
  1. The use case begins when a Manual Payment Customer receives a billing statement email sent by the Email Billing Statement use case.
  2. The customer follows the payment instructions included in the Billing Statement, writes a check, and mails it to Sermons Online billing.
3.1. Accept Manual Payment
  1. The use case begins when a payment for a Sermons Online invoice is received in the mail.
  2. The Sermons Online Billing actor finds the Sermons Online transactions to apply the payment to, and clears them. Any partial/remaining payment amounts are entered as credit transactions.
  3. The Billing actor deposits the check.
  4. The use case ends.