In this release, the integration supports payment by a taxpayer using a bank or credit card number. The following diagram illustrates an expected process flow.
The integration has the following steps:
Initial processing works as follows:
Enrolled user. The identification is not performed.
Once identified, the casual user indicates what the payment is for. This is referred to as the target of the payment or the payment destination or the payment details. For example, is this a payment for a pay plan scheduled payment? If so, the taxpayer must provide the pay plan identifier. Once the taxpayer indicates the payment target details, another web service request is sent to this product to verify the details.
When the enrolled user is browsing a specific tax account it becomes possible to retrieve payments that are currently due and present user with the pre-populated list so the user will choose what to pay rather than enter payment details manually.
Next, the taxpayer indicates the method of payment:
If the method is via a credit card and the implementation uses an external payment vendor, the self service application sends a web service request to this product to retrieve any additional information about the taxpayer that may need to be sent to the external vendor (such as the taxpayer's address) and to determine if the external vendor's fee should be passed on to the taxpayer. At that point the taxpayer is taken to the external vendor's website to further process the payment details. Once that step is complete a final web service request is sent to this product to process the payment.
If the method is via a bank account or if the implementation does not use an external payment vendor for credit card payments, the self service application sends a web service to this product to create the payment. The standard Auto Pay logic in the product is used to process the payment.
If the external vendor supports payment reconciliation, the subsequent reconciliation report is processed by the product.
The topics below describe more information about the provided functionality, followed by configuration tasks.
In this release the integration supports payments by an 'unregistered' taxpayer. The taxpayer does not need to log in using a user name and password in order to submit a payment. In addition, the product supports a person paying on behalf of another taxpayer.
The taxpayer must provide enough information to be identified by the system prior to proceeding. A special service task business object is provided for identifying a taxpayer for one-time payments (C1-TaxpayerIdentifySSTask).
Refer to Configuration Tasks for Online Payment for more information.
When creating a payment, the product supports using distribution rules to determine where the payment should be targeted. The integration provides out of the box support for the following payment destinations.
Pay a filing period. This method allows the taxpayer to provide their taxpayer ID, a tax type and a filing period to direct the payment to.
Pay a pay plan. This method allows the taxpayer to provide a reference to a pay plan to pay one or more of the scheduled payments.
Pay a collection notice. This method assumes that a collection notice has been issued from a customer contact in the system and that the customer contact ID has been provided to the taxpayer as an identifier.
Pay a Form (DLN Only). This method assumes that a tax or business registration form was processed by the system and the Document Locator Number has been provided to the taxpayer.
Pay an Obligation. This method allows taxpayer to provide the exact ID of the obligation and pay obligation's balance.
Pay a Tax Role Balance. This method allows taxpayer to provide the exact tax role ID and pay an outstanding tax role balance.
Pay a Tax Form. This method allows the taxpayer to provide a DLN of the form that is not necessarily exists in the system yet. The assumption is that this method would be used for payments immediately following the on-line form submission for the scenario where the form submission web service request is queued by the integration while the payment request is processed immediately.
The business object provided by the product for processing one time payments has been designed to support different payment destinations. To do this, the business object must support receiving different types of information (for example, pay plan ID or collection notice ID) and use plug-ins that are specific to each payment destination that knows the type of data expected, how to use that data to identify the correct account and obligation(s) and process the payment successfully. At a high level it works as follows:
The web service requests sent by the self service application to validate the payment target and to process the payment include an indication of the payment destination and a field/value pair collection to hold the values that represent the 'target' for the payment.
The self service master configuration record includes a mapping between the payment destination and a self service task type.
The service task type for each unique payment destination references a "processor" service, which can be a service script or a business service. This service should be specific for a given payment destination and expects the data appropriate for it. For example, the process to "pay a pay plan" expects the service task's destination details to specify a pay plan ID.
The service task type includes a field mapping section. This mapping indicates which field value in the destination details list to populate in which target XPath in the "processor" service.
The web service called to validate the destination details provided by the taxpayer invokes the "processor" to ensure that the data can be found.
When processing the payment, the service task that processes payments includes an algorithm that uses the configuration on the task type to call the "processor" service, passing the details of the payment target.
The processor is used to verify if the input account is valid for the entity identified by the current access information. If the account is invalid it returns an error.
When creating a new custom Processor, use any of the base business services or service scripts provided as an example of the type of functionality needed. All base components provided begin with C1-OTPVAc%. The processor may be implemented as a service script or a business service.
The custom service, whether it be a service script or a business service should include the data area C1-SelfServiceKeys along with an <accountId> element
The web service used to retrieve the list of outstanding payments is processed by the XAI Inbound Service TSRetrievePaymentsDue, which invokes the service script C1-RtPymtDue.
The web service request contains:
The service script determines the service task type based on the payment destination (via master configuration). It then calls the retrieve payments due processor. The processor should return a collection of the prospective payments. Each entry contains:
The parameters for the obligation info display are obligation type and payment due date.
The web service used to validate the payment destination information entered by the taxpayer is processed by the XAI Inbound Service TSPrepareExtPaymentData, which invokes the service script C1-PrExPyDta with an action of VALIDATEONLY. The service script determines the service task type based on the payment destination (via master configuration). It then calls the payment destination details processor with an action of "validate only". The processor should return an error if the information provided by the taxpayer does not identify an appropriate related object for the payment destination.
If the enrolled user is making a payment, the service script calls an additional processor that checks if the account determined during the destination details validation is relevant for the tax account in context (access type+ access keys).
The web service request to create a payment is processed by the XAI Inbound Service TSOneTimePayment, which invokes the service script C1-PyUnrgUsr. The service script is responsible for creating a Service Task of the correct service task type based on the payment destination.
When a taxpayer provides bank account information for payment in self service, the payment detail is sent to this system and the integration with the customer's bank is handled through standard auto pay processing. This method may also be used to process credit cards. However, it's expected that an integration with an external vendor will most often be used for that. Refer to the section below for more information on external payment vendors.
Many tax authorities require taxpayers to sign an automatic payment agreement prior to allowing them to submit tax payments online. The product supports checking for a reference to an ACH agreement that is defined as a characteristic linked to the taxpayer's record.
The one-time payment service task provided by the base product includes the following basic lifecycle states:
Pending. When the web service request is processed, a service task is created in pending status. Initial validation is performed, including verifying that the information provided for the payment destination and determining the appropriate account to associate with the payment. If any issues are found, the service task is not stored and an error is returned. Once the record is validated, no further processing occurs at this time. When the service task monitor is run all pending records are further processed.
In Progress. When transitioning to this status, the payment is processed. The data related to the payment destination is mapped to appropriate payment event distribution details and the payment is created. If any errors are encountered, the service task transitions to Error. If the payment was processed through an external vendor that requires reconciliation, it transitions to Pending Reconciliation. Otherwise, it transitions to Complete.
Error. Any errors detected in payment processing or during reconciliation processing causes the service task to transition to this state and creates a To Do entry. A user must review and resolve the problem.
Error Resolved. When a user resolves the error reported the service task can be transitioned to this state. Note that the assumption is that the user has manually corrected the error. This state does not cause any logic to occur.
Pending Reconciliation. When a payment is made through an external vendor that requires reconciliation, the service task transitions to this state and waits for the reconciliation process. Refer to the external payment vendor section below for more information about reconciliation. Note that this state is configured with time out logic. The payment vendor can be configured with a number of days to wait for the reconciliation report. If that number of days passes, a To Do entry is created using an appropriate To Do type defined for the payment vendor.
Complete. Service tasks transition to this state when the payment is fully processed.
Many websites integrate with an external payment vender to process credit cards real-time. In this case, the following functionality is provided:
Preparing External Payment Data. After the standard steps of identifying the taxpayer and validating the payment destination, when a taxpayer indicates payment using a credit card, the self service system sends a web service request to this product to determine whether a fee is applicable and to return additional payment data.
Payment processing. Once the credit card information is processed by the external vendor, a web service request with the payment information is sent to this system. This causes an appropriate service task to be created to process the payment and apply it to the taxpayer's balance appropriately.
Reconciliation. External vendors may supply reconciliation information for all the payments that were processed in a given time period. The product supports the ability to receive the reconciliation information, compare it against our records and highlight any discrepancies.
Refer to the self service documentation for more information about configuring the system to work with external vendors.
The following topics provide additional detail about the integration functionality provided.
The following diagram illustrates the prepare external payment data and payment processing components for the integration with OPC.
Prepare External Payment Data
Once the taxpayer has indicated that payment will be made by credit card, the self service application sends a web service request to determine the fee requirement and to retrieve detail about the taxpayer to provide to the external vendor. These are processed by the XAI Inbound Service TSPrepareExtPaymentData, with an action of PREPARE, which invokes the service script C1-PrExPyDta. This script does the following:
It uses the payment destination to determine the appropriate service task type (via the master configuration) and uses this information to determine the fee requirements. External vendors often charge fees for using their service. The tax authority may to choose to pass the fee onto the taxpayer or to absorb the cost of the fee. The product supplies configuration to allow the tax authority to define for each service task type whether taxpayers should be charged the fee based on the person's person type.
It retrieves additional information about the taxpayer, if required by the external vendor. It looks for a Prepare Data service script linked to the external vendor's record. If one is defined it is called. Refer to Configuration Tasks for Payment Vendors for more information.
Payment Processing
For the most part, the payment processing for these payments is analogous to the processing done for bank payments. The tender type used should be one that is not configured to integrate bank details. And an external reference to the payment vendor's record should be recorded with the service task using a characteristic. This allows the reconciliation process to identify the record.
The product supports capturing additional information as defined by the requirements for the external vendor. The data is stored in a "raw" element on the service task called externalPaymentData. The structure of the information captured must be defined using the External Payment Data Area linked to the payment vendor lookup.
Reconciliation
The following diagram illustrates the reconciliation component for the integration with OPC.
Once the service task successfully creates the payment, it checks whether reconciliation with the payment vendor is applicable and if so, it transitions to the Pending Reconciliation state to wait for the reconciliation details.
When the reconciliation details are processed, individual web service calls are sent to the system for each payment. These are processed by the XAI Inbound Service TSProcessExtPayReportRecord, which invokes the service script C1-PrcPyRpRc. This script uses the external reference to find an existing payment service task in the Pending Reconciliation state with this reference linked as a characteristic.
Refer to Configuration Tasks for Payment Vendors for more information.
Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved. Documentation build: 2.5.2016 10:21:45 [T1_1454696505000]