リリース12
E06000-01
目次
前へ
次へ
| Oracle Paymentsインプリメンテーション・ガイド リリース12 E06000-01 | 目次 | 前へ | 次へ |
Oracle Paymentsの資金取得側と資金支出側の両方に共通の支払機能は、次のとおりです。
アクセス管理
API
サーブレット
伝送
セキュリティ
アクセス管理は、データの表示または更新（あるいはその両方）におけるユーザー・アクセスを管理できるOracle Paymentsの機能です。主に取引データの保護に使用され、ユーザーのセキュリティ・プロファイルによって管理されます。複数組織に関する権限で管理されるOracle Paymentsのアクセス管理は、複数組織アクセス管理（MOAC）と呼ばれます。MOACはOracle HRMS（人事管理システム）のプロファイルを使用して設定されます。このプロファイルで、ユーザーがアクセス可能な組織または組織の階層を指定します。プロファイルは、ユーザー、職責または他のレベルに割り当てられます。
企業は、パフォーマンスと費用削減を最大化するために、様々な方法でビジネス単位をモデル化します。Oracle Paymentsは、各種の支払モデルをサポートするように構成できます。完全に分散化されたモデル内で動作可能で、この場合は企業内の各組織で独自の財務活動が処理されます。または、企業が共有サービス・センターで財務活動を一元化しようとする場合は、共有サービス・センター・モデルも効率的にサポートできます。
さらに、Oracle Paymentsでは、支払ファクトリ・モデルを使用する企業がサポートされます。支払ファクトリを使用すると、営業単位は独自の買掛管理およびその他の支払管理機能を保守できます。支払ファクトリは、採用企業の銀行業務パートナとの通信および取引を処理します。請求書選択は、Oracle Payablesで単一の営業単位内で実施されます。この結果、支払ファクトリ管理者は、Oracle Paymentsを使用して、異なる営業単位の支払を伝送および精算用の1つの支払ファイルに連結できるため、取引原価を削減できます。
支払機能には、ソース製品によって行われる支払または取得される支払のタイプがあります。各買掛/未払金文書に支払機能が設定されます。たとえば、Oracle Payablesでは、仕入先などに支払を行う支払機能がサポートされます。様々なアプリケーションに様々な支払機能があります。Oracle Paymentsでは、各ユーザーを特定の支払機能に制限できます。
Oracle Paymentsでは、複数組織アクセス管理（MOAC）がサポートされます。MOACはアクセス管理のサブ機能で、Oracle Applicationsの単一インストール内で、複数組織とその組織の関係を定義できます。これらの組織には、営業単位、ビジネス・グループ、法的エンティティ、会計帳簿または在庫組織などがあります。
MOACの主な利点は、様々な職責にログインすることなく、異なる営業単位内の文書に関する処理を実行できることです。データ・セキュリティは、セキュリティ・プロファイルを使用して保守されます。セキュリティ・プロファイルは、特定のユーザーにデータ・アクセス権限が付与されている営業単位のリストに対して定義されます。
読取り専用ページでは、アクセス権限がある文書または支払のみを表示できます。つまり、表示されるデータは、アクセス権限があるデータです。
逆に言うと、アクセス権限のない組織または支払機能に関する文書または支払を表示することはできません。ただし、支払プロセス要求、支払指図および資金精算バッチには、複数組織のデータが含まれる場合があり、組織固有ではありません。このような場合、要求、指図または精算バッチ内のデータを所有している組織に対するアクセス権限がある場合は、これらを参照できます。しかし、その要求、指図または精算バッチ内で表示できる取引データは、アクセス権限がある組織が所有しているデータのみです。
処理ページとは、買掛/未払金文書、支払、支払プロセス要求、支払指図、資金精算取引または精算バッチに関するあらゆる種類の処理を実行するページです。小切手の印刷、検証エラーの修正、資金取得および資金支出ダッシュボードにおけるその他の処理の実行などがあります。エンティティに関する処理を実行できるのは、エンティティ内の全データに対するアクセス権限がある場合のみです。たとえば、支払指図に組織1と組織2に対する支払が含まれていて、組織1に対するアクセス権限のみがある場合、その支払指図に対する処理ページにはアクセスできません。つまり、オブジェクト内のデータに対して部分アクセス権限しかない場合、そのオブジェクトにはアクセスできません。この場合、オブジェクトに対するフル・アクセス権限がないことを示すメッセージが表示されます。
支出システム・オプション設定ページでは、アクセス権限がある組織に対する組織レベルのシステム・オプションのみを表示および更新できます。Oracle Paymentsによって、表示および更新できる内容が、アクセス権限がある内容のみに制限されます。
他のすべての設定ページでは、アクセス管理に関係なく、表示および更新できる内容は制限されません。
次のコンカレント・プログラムは、組織に対するアクセス権限によって制限されます。
支払指示の作成: 資金支出。このプログラムでは、ユーザーに処理権限がある支払のみが選択されます。
精算バッチの作成: 資金取得。このプログラムでは、ユーザーに権限がある取引のみが選択されます。
Oracle Paymentsには、支払処理について既存または新規のアプリケーションとOracle Paymentsの統合を簡素化するために、2種類のAPIが用意されています。
Oracle Applications API: Oracle Applicationsは、これらのAPIを使用して、資金取得および資金支出についてOracle Paymentsと統合します。これらはOracle Applicationsの内部機能です。
電子商取引API: 第三者アプリケーションは、これらのAPIを使用して、資金精算取引についてそのアプリケーションとOracle Paymentsを統合できます。第三者アプリケーションは、Java APIまたはPL/SQL APIを介してOracle Paymentsと通信するスタンドアロン・アプリケーションです。
支払システム統合: XMLパブリッシャ・テンプレート、伝送構成および支払システム・サーブレットを作成または更新することによって、支払システムと統合できます。テンプレートは、支払データを支払システムのフォーマットに変換するために使用されます。伝送構成には、支払システムへの伝送の詳細が含まれ、サーブレットによって実際の伝送処理が管理されます。Oracle Paymentsには、支払ゲートウェイおよび支払プロセッサとインタフェースするための支払システム統合モデルが用意されています。
Oracle Paymentsは次のサーブレットで構成されています。
ECServlet
ECServletは、承認などの支払関連の資金取得操作を処理するOracle Paymentsエンジンへのインタフェースを提供します。このサーブレットは主に、Oracle Paymentsが提供するPL/SQL APIに対して使用されます。
支払システム・サーブレットは、Oracle Paymentsでフォーマットされた支払ファイルを取得して、そのファイルをOracle Paymentsで設定された伝送構成に従って支払システムに伝送します。Oracle Paymentsには、Oracleが開発した支払システム・サーブレットまたはその支払システム・パートナが開発したサーブレットとのインタフェース（あるいはその両方）がバンドルされています。支払システムは、支払アクワイアラ（銀行）と通信して、支払取引を処理します。Oracle Paymentsには、Paymentech、First Data（North）およびConcord EFSnet用の支払システム・サーブレットが含まれています。VeriSignなど、一部の支払システムは、独自のOracle Paymentsサーブレットを作成しています。
フィールド・インストール可能サーブレット
Oracle Paymentsでは、フィールド・インストール可能サーブレットがサポートされています。これらの支払システム・サーブレットは、Oracle Paymentsにバンドルされていません。この機能を使用すると、受取人は、新しい追加のシステム・サーブレットまたはアップグレードされたシステム・サーブレットを入手し、Oracle Paymentsにバンドルされている支払システム・サーブレットと同じ方法で構成できます。
フィールド・インストール可能サーブレットを追加する機能によって、支払に柔軟性が加わり、Oracle Paymentsの新規リリースおよび支払システムは相互に独立した関係を保つことができます。また、ソース製品のユーザーが、特定のニーズや地域用に支払システムをカスタマイズすることもできます。
Oracle Payments用のフィールド・インストール可能支払システム・サーブレットは、Oracleの支払システム・パートナから入手するか、またはカスタム作成が可能です。
支払システムとの間でデータを伝送するには、伝送プロトコルおよび伝送構成が必要です。最初に、伝送方法を定義する伝送プロトコルを設定する必要があります。具体的な伝送詳細を指定する伝送構成は、1つの伝送プロトコルと関連付ける必要があります。
実例をあげると、Oracle Paymentsでは、静的ファイル名のファイル転送プロトコルと呼ばれるフラット・ファイル用の汎用伝送プロトコルがサポートされています。このプロトコルは、データを電子伝送する一般的な方法です。これに対して、FTP to Paymentechは、FTPを伝送方法として、特定の場所へのデータ伝送方法を指定する特殊な伝送構成です。
資金取得側では、伝送プロトコルと伝送構成が資金取得プロセス・プロファイルに関連付けられます。一方、資金支出側では、伝送構成が支払プロセス・プロファイルに関連付けられます。
Oracle Paymentsにシードされている伝送プロトコルは、すべての資金取得プロセス・プロファイルで使用され、支払プロセス・プロファイルで使用される場合もあります。これらの共通シード・プロトコル（FTPなど）の構成要素は、次のとおりです。
コード入力ポイント。支払システム・サーブレットにより伝送の実行に使用されます。
ネットワーク・アドレスやポートなどのパラメータ・リスト。伝送構成によって値を指定する必要があります。
伝送プロトコル入力ポイント。支払サーブレットから独立しており、Oracle Paymentsエンジンから起動できます。
シード伝送プロトコルは、Oracle Paymentsの設定ページで表示できます。
各伝送プロトコルには、値を必要とするパラメータがあります。パラメータに定義される値によって、伝送プロトコルの伝送構成が構成されます。たとえば、支払システムPaymentechには、特にソケットIPアドレスXとソケット・ポート番号Yが必要です。XYと他の値によって、特定の伝送プロトコル用の伝送構成Aが表されます。
Oracle Paymentsでは、機密性の高い財務データが保存され、処理されます。このデータの適切なセキュリティを保証するために、Oracle Paymentsには高度なセキュリティ機能が備わっています。データのセキュリティおよびプライバシを保証するための機能がいくつかあります。
この項では、Oracle Paymentsのセキュリティ機能、およびこれらの機能を適切に利用するために必要な設定について説明します。
MOAC（複数組織アクセス管理）は、Oracle Paymentsのセキュリティ機能の一部です。MOACの詳細は、「複数組織アクセス管理（MOAC）」を参照してください。
支払手段暗号化は、Oracle Applicationsでクレジット・カード・データを暗号化できるようにするOracle Paymentsの高度なセキュリティ機能です。この機能は、クレジット・カード業界（PCI）のデータ・セキュリティ基準のカード所有者データ保護要件、およびVisa社のカード所有者情報保護プログラム（CISP）への準拠に役立ちます。Visa社のプログラムは、PCIデータ・セキュリティ基準に基づいています。機能を使用可能にすると、顧客、仕入先または受講者など、外部の第三者のクレジット・カード番号および銀行口座番号が暗号化されます。
注意: iExpensesなどの他の製品では、内部クレジット・カード番号はOracle Paymentsの表に格納されます。
クレジット・カード暗号化機能の採用は、組織に固有の完全なセキュリティ・ポリシーの実装の一部にする必要があります。たとえば、セキュリティ・ポリシーには、支払手段データを保護するために、キーを周期的に変更する定期的なスケジュールを組み込む必要があります。Oracle E-Business Suiteアプリケーションの製品の保護に関する一般的なガイドラインは、『Best Practices for Securing Oracle E-Business Suite』（Oracle MetaLink Document 189367.1）を参照してください。
Oracle Paymentsのアーキテクチャを使用すると、ファイアウォールの外側のマシンに支払システム・サーブレットをインストールできます。Oracle Payments（またはそのコンポーネント）またはソース製品のいずれかを分散環境にインストールしている場合は、Oracle Paymentsと支払システム・コンポーネントの間にSSLを構成することをお薦めします。Oracle Walletを作成すると、エンジン（この場合はサーブレットのクライアント）の認証をサポートするための証明書と資格証明の情報を、サーブレットを実行しているサーバーごとに格納できます。Walletの場所とパスワードはFNDプロファイルを使用して指定できます。サーブレットが実行されているサーバーを、（エンジン側の）クライアント証明書を要求するように構成できます。Oracle Paymentsは、Oracle Walletから証明書を取得し、認証のためにサーバーに送信します。また、支払システムの基本認証がサーブレットによってサポートされます。
これらのセキュリティ機能は、データおよびOracle Paymentsサービスに対する無許可アクセスから保護するために使用することをお薦めします。Oracle iAS Webサーバー（Apacheサーバー）には、サーバー、リスナーおよびサーブレットの保護に使用できる数種類の認証が用意されています。
Oracle Paymentsと支払システム・サーブレットは、ファイアウォールの内側にあるマシンにインストールすることをお薦めします。
Oracle Payments（またはそのコンポーネント）またはソース製品のいずれかが分散環境にインストールされている場合は、Oracle Paymentsと支払システム・コンポーネント間でSSL通信を使用可能にすることをお薦めします。
Oracle Paymentsと支払システム・サーブレット間の基本認証に関するセキュリティを設定するために、Oracle Paymentsの設定ユーザー・インタフェースとApacheサーバー管理ツールの両方でいくつかのタスクを実行する必要があります。特定の支払システム用にOracle Paymentsを構成すると同時に、支払システムの構成画面で、支払システムにユーザー名とパスワードを割り当てる必要があります。また、同じユーザー名とパスワードを、支払システム・サーブレットを実行するApacheサーバーで割り当てる必要があります。
Apacheサーバーで基本認証を設定する方法の詳細は、Apacheサーバーのマニュアルを参照してください。
業者のユーザー名とパスワードを使用する以外に、IPアドレス制限によって、Oracle Paymentsと支払システムへのアクセスを制限できます。Apacheサーバーの機能であるIPアドレス制限を使用すると、次のいずれかまたは両方のパラメータを指定できます。
すべての信頼されたホスト（WebサーバーがOracle Paymentsに対する取引要求を受け入れるマシン）のIPアドレス
いくつかの信頼されていないホスト（WebサーバーがOracle Paymentsに対する取引要求を拒否するマシン）のIPアドレス
信頼されたリストのマシンからの要求の場合は、Oracle Paymentsが要求された取引を処理します。信頼されていないリストのマシンからの要求の場合は、Apacheサーバーが要求を拒否し、Oracle Paymentsで要求が処理されないようにします。
IPアドレス制限によって、すべての操作に対する信頼されていないマシンからのアクセスを制限できます。
信頼されたホストの指定方法など、IPアドレス制限に関する詳細は、Apacheサーバーのマニュアルを参照してください。
サイト管理とOracle Payments管理に別々のHTTPポートを使用すると、セキュリティが強化されます。
関連項目
Oracle Walletの詳細は、『Oracle Applicationsシステム管理者ガイド - セキュリティ』を参照してください。
この項では、資金取得プロセスに関連する機能と用語について説明します。
資金取得側の資金取得プロセス・プロファイルは、Oracle Paymentsに支払システムとの通信方法を指示する情報が含まれた設計図です。次に示す資金取得管理プロセスの各ステップに関する情報が含まれています。
銀行口座振替のオンライン支払人検証、クレジット・カード支払のオンライン承認またはデビット・カード支払のオンライン引落し
通知
承認
精算からバッチを作成するためのルール
資金取得側の資金取得プロセス・プロファイルの役割は、資金支出側の支払プロセス・プロファイルと同じです。資金取得プロセス・プロファイルは、前述のように、すべての資金取得操作の動作をアクセス管理するために定義されます。ただし、支払プロセス・プロファイルと異なり、資金取得プロセス・プロファイルは常に、受取人設定時に作成されるルーティング・ルールから導出されます。
また、資金取得プロセス・プロファイルでは、取引の処理に使用される支払システム・アカウントも指定されます。
Oracle Paymentsの資金取得側での支払方法は、第三者支払人が第一者受取人への支払送金のために選択する手段です。たとえば、ある顧客は製品またはサービスの支払を採用企業に送金します。Oracle Paymentsは、自動資金取得処理について、次の支払方法をサポートしています。
銀行口座振替
クレジット・カード
暗証番号不要のデビット・カード
受取手形送金
Oracle Paymentsを使用すると、次のように、資金取得支払方法を柔軟に設定できます。
銀行口座振替の一意の支払方法を定義できます。
Oracle Paymentsは、クレジット・カードおよび暗証番号不要のデビット・カードの単一支払方法をシードします。
Oracle Paymentsでは、受取人は、顧客から資金を回収する第一者エンティティを表します（資金取得支払の場合）。また、受取人には、支払システムとの間に、支払システムが受取人に関する取引を処理するというビジネス関係があります。
Oracle Paymentsでは、資金取得について複数の受取人を設定できます。複数の受取人を設定できる理由は、たとえば、1つの組織内の異なるビジネス単位または法的エンティティが別々の支払システムによって取引を処理する場合や、支払システムとの個別の関係を使用する場合があるためです。
Oracle Paymentsで受取人を作成する際は、いくつかの情報を指定する必要があります。
受取人が取引を処理する対象の組織
受取人が受け入れる支払手段タイプのリスト
受取人が取引の処理に使用する支払システム・アカウントと資金取得プロセス・プロファイル
リスク算式
ルーティング・ルール
Oracle Paymentsは、企業全体の支払処理を提供するために他のOracle Applicationsと統合されています。様々なソース製品が、取引要求を処理のためにOracle Paymentsに送信します。Oracle Paymentsがない場合、これらの各アプリケーションは、支払システムに対する独自の統合を作成する必要があります。Oracle Paymentsは、Concord EFSnet、First Data Northなどの支払システム、および他の各国固有または地域固有の支払システムに対する単一のソースを提供することによって、統合作業を不要にします。
セールス・アプリケーション（例: iStoreまたはTeleSales）: 顧客が製品を購入し、クレジット・カードで支払うことにします。セールス・アプリケーションはオーダーを発行します。
Order CaptureまたはOrder Management: Order CaptureおよびOrder Managementが受注を処理します。両方のアプリケーションがOracle Paymentsを使用して、クレジット・カード番号が有効であるかどうかを検証し、受注金額を承認します。また、承認の一部として、一部のリスク評価も実行できます。
Oracle Receivables: 受注が出荷されると、取引情報がOracle Receivablesに渡され、請求が行われます。
Oracle Collections: 支払の期限を超過し、コール・センターで資金支出回収試行を開始すると、Oracle Collectionsは、Oracle Paymentsを使用して、クレジット・カード取引を承認し、精算します。
Oracle PaymentsとOracle Applicationsの統合
資金取得支払のうち、Oracle Paymentsはクレジット・カード取引、暗証番号不要のデビット・カード取引、購買カード取引およびEFT取引を処理します。この項では、一般的なクレジット・カード取引のフローについて説明します。
従来のクレジット・カード取引の処理には、第三者支払人、第一者受取人、発行銀行、取得銀行、支払プロセッサ、およびオプションで支払ゲートウェイが関係します。
クレジット・カード取引は、承認と精算の2つのフェーズで構成されます。一般的なフローは、次のように行われます。
承認
第三者支払人が商品またはサービスを購入し、発注または請求書の一部として第一者受取人にクレジット・カード情報を送信します。
第一者受取人は発注を受け入れ、Oracle Paymentsおよび必要に応じて支払ゲートウェイを介して支払プロセッサに承認要求を送信します。
支払プロセッサは、送信された情報と発行銀行が保持するデータベースを照合し、顧客のクレジットが取引を支払うのに十分かどうかを判断します。十分と判断した場合、支払プロセッサは資金を引き当て、承認コードをOracle Paymentsに返します。
第一者受取人は商品を顧客に搬送し、取引を精算、つまり承認で引き当てられた資金を取得する必要があります。精算は、承認と同時に行われる場合があります。精算取引には、バッチ管理が含まれます。
第一者受取人は、Oracle Paymentsおよび必要に応じて支払ゲートウェイを介して支払プロセッサに取得、無効、差戻し、クレジットおよび精算バッチ関数を発行します。
支払プロセッサは発行銀行で支払を決済し、資金を取得銀行に送金します。
クレジット・カード処理ネットワークは、取引を完了するために業者がカード所有者の発行銀行に電話する必要があることを示す照会メッセージ付きの取引を拒否する場合があります。このような場合、支払情報は電話で発行されます。取引が承認されると、業者には取引の承認コードが付与されます。この音声承認に対するOracle Paymentsによる後続取引（取得、無効など）を容易にするために、Oracle Paymentsでは、ゲートウェイ・モデルおよびプロセッサ・モデルの支払システムに対する音声承認サポートが提供されています。
購買カードは、組織が従業員に発行するクレジット・カードの一種です。通常、購買カードは、企業の商品およびサービスを購入するために従業員が使用します。支払は、企業の購買担当がカード・イシュアに対して行います。
ビジネスでは、商品およびサービスを入手するための費用を削減し、労働集約型の処理を簡素化するために購買カードを使用します。この結果、多くの購買担当は、購買カードを受け入れる業者を優先します。
業者は通常、購買カードでクレジット・カードより高い利率をカード会社または発行銀行から受け取ります。
発注番号や他の情報の提供による消込ストリームの改善。
企業で複数の購買カードに対して1つの請求書を受け取る場合の購買の集約性。
発注プロセスの簡略化。購買プロセスの単純化、文書業務の削減、および費用限度額管理の自動化による処理費用の低減。
購買カードを受け入れる業者が購買情報を電子的に使用可能にすることによって、購買担当の作業が軽減されます。この情報は、企業（購買担当）にとって、税規約への準拠、レポート要件および費用消込に役立つ場合があります。
購買カードでは、3つのレベルのデータを取得し、業者が支払システムを介して購買担当組織に送信できます。3つのレベルは次のとおりです。
レベルIの取引データは、基本的なデータのみで構成されます。標準的なクレジット・カード取引では、レベルIデータをプロセッサに提供します。業者がレベルIデータのみを渡す場合、購買担当は購買カードの利用によって特別な利益を得ることはできません。
レベルII取引データは、レベルIデータ以外に、税金金額やオーダー番号などのデータで構成されます。
レベルIII明細品目詳細は、品目摘要、数量、単位、価格など、特定の購買情報を提供します。この情報は、会計およびビジネス手法を合理化し、支払データと電子調達システムをマージする購買担当に役立ちます。次の表のデータは目安にすぎません。実際のフィールドは、支払システムによって異なります。
注意: Oracle Paymentsは、支払プロセッサとゲートウェイ・モデル支払システムの両方でレベルIIIデータをサポートしています。
次の表は、各レベルでOracle Paymentsによって渡されるデータに関する情報を示しています。
| データ | レベル1 | レベル2 | レベル3 |
|---|---|---|---|
| カード番号 | X | X | X |
| カード所有者名 | X | X | X |
| カード有効期限日付 | X | X | X |
| カード所有者請求先所在地 | X | X | X |
| 通貨コード | X | X | X |
| 税金金額 | X | X | |
| 取引/オーダー番号 | X | X | |
| 出荷元郵便番号 | X | X | |
| 搬送先郵便番号 | X | X | |
| 割引額 | X | ||
| 運送費 | X | ||
| 関税額 | X | ||
| 明細品目情報 | X |
購買カード取引の取引フェーズは、クレジット・カード取引と同じで、承認と精算です。取引フェーズの詳細は、「クレジット・カード取引について」を参照してください。
Oracle Paymentsでは、一連のシード済カード番号範囲に基づいて購買カードが自動的に認識されます。Oracle Paymentsは、精算または精算バッチ操作中にゲートウェイ・オンライン要求を介して支払システムに追加情報を渡します。承認およびその他の精算操作は、クレジット・カードの場合と同じように、購買カードの同じ情報を渡します。
暗証番号不要のデビット・カード取引は、選択した産業内で従来から定型請求者とみなされている第一者受取人に対して、一部の支払システムによって提供される支払方法の1つです。消費者は、PINを提供することなくデビット・カード支払プロセスを開始します。業者は、消費者を認証し、その取引と後続のすべての修正に対して100%責任を負います。
ほとんどのゲートウェイ・タイプ支払システムは、暗証番号不要のデビット・カード取引を単一ステップで処理します。承認要求を受信した後、支払システムはデビット・ネットワークに取引を送信します。承認要求を承認した後、消費者の口座（支払人）に請求されます。業者の口座（受取人）は、後でクレジットされます。暗証番号不要のデビット・カード取引は、承認と資金取得が2つのステップに分かれるクレジット・カード取引のプロセス・フローとは異なります。
ソース製品の統合を容易にするために、Paymentsでは、承認は必須ですが、精算はオプションです。
承認ステップでは、取引を支払システムにルーティングおよび送信し、取引をOracle Paymentsに保存し、承認応答をソース製品に戻します（クレジット・カードと同様）。
ソース製品が精算を起動すると、元の取引がOracle Paymentsスキーマから取り出されます。取引が承認された場合は、成功メッセージがソース製品に戻されます。
ほとんどの支払プロセッサでは、暗証番号不要のデビット・カードのフローは、支払ゲートウェイの場合と同じです。ただし、Paymentechなどの一部のプロセッサ・タイプ支払システムでは、取引を完了するために追加の精算ステップが必要です。第一者支払人の口座は精算後にクレジットされ、送金が完了したことになります。
ソース製品の統合を容易にするために、Paymentsでは、承認は必須ですが、精算はオプションです。支払システムで精算ステップが必要な場合、Paymentsはソース製品からの入力なしで、そのステップを自動的に実行します。
ゲートウェイの場合と同様に、ソース製品が精算を起動すると、元の取引がOracle Paymentsから取り出されます。取引が承認された場合は、成功メッセージがソース製品に戻されます。
Oracle Paymentsでは、BtoCとBtoBの両方のモデルに対して、資金取得の銀行口座振替がサポートされています。資金取得の銀行振替機能によって、顧客の銀行口座から受取人の銀行口座への支払金額の電子転送が容易になります。
EFTオンライン検証は、一部の支払システムが提供するリアルタイムのサービスで、EFT取引で使用される第三者支払人の銀行口座を検証します。EFTオンライン検証サービスでは、第三者支払人の銀行口座手段が存在し、不正のアラートがないことが保証されます。電子送金取引は、取引の完了に1営業日から2営業日が必要であるため、リアルタイムでは行われません。したがって、銀行口座がまだ開いており、十分な資金があることは保証できません。EFTオンライン検証は、次のように、妥当性チェックをサポートします。
検証ステップは、EFT取引のオプション・ステップです。任意の回数実行できます。
検証はリアルタイムで行われます。
EFTオンライン検証応答メッセージは、プロセッサ・タイプ支払システムのクレジット・カード承認応答メッセージと同じメッセージ標準を共有します。
注意: EFTオンライン検証は米国のACHに対してのみ提供され、すべての支払システムに対して提供されるわけではありません。EFTオンライン検証では、銀行口座が存在しているかどうか、および口座に不正のフラグが付いていないことがチェックされます。また、資金の引当は行われず、口座に十分な資金があるかどうかはチェックされません。
Oracle Paymentsは、ゲートウェイ・モデルとプロセッサ・モデルの両方の支払システムをサポートします。プロセッサ・モデルは、Oracle Paymentsと支払プロセッサの間のインタフェースを記述します。支払プロセッサは、銀行やカード会社（Visa社、Mastercard社およびAmerican Express社など）と直接やりとりして、財務取引を処理するサービスです。ゲートウェイ・モデルは、Oracle Paymentsと支払ゲートウェイの間のインタフェースを記述します。支払ゲートウェイは、第一者受取人と支払プロセッサの間の仲介として機能するサービスです。
ゲートウェイ・モデルの支払システムに統合するか、プロセッサ・モデルの支払システムに統合するかの選択は、一般的に、ビジネス・タイプ、1日当りの取引件数および取得銀行によって決定されます。プロセッサには通常、より厳密なセキュリティ、接続性およびテスト要件があります。ゲートウェイは、SSLベースのインターネット接続を使用することが多く、使いやすさを提供します。ゲートウェイには、プロセッサでかかる手数料の他に、追加の手数料（取引ごとの手数料を含む）がかかります。通常、価格設定は支払システムごとに異なります。プロセッサ・モデルの支払システムは、多くの場合、プロセッサ接続の労力と費用を費やしてもかまわない取引量の多い業者に適しています。ゲートウェイ・モデルは、取引量の少ない業者、または設定および接続を容易にするために取引ごとの手数料を支払ってもかまわない業者に適しています。
ゲートウェイ・ベースのシステムでは、すべての取引がオンラインで取得されます。プロセッサ・ベースのシステムでは、承認はリアルタイムで実行され、精算やクレジットなどの後続の取引はオフラインで実行されます。オフライン取引は1つにまとめられ、単一の要求として支払システムに送信される必要があります。承認以外の取引はすべて、デフォルトでオフラインで実行されます。オフライン取引は、次の精算バッチ操作試行時にプロセッサに送信されます。
精算バッチは、資金取得プロセス・ホームまたはコンカレント要求マネージャを使用して、手動で作成するか、またはスケジュールに従って自動的に作成できます。また、精算バッチ内の取引の最終ステータスを取得するには、決済情報を取得します。これにも、資金取得プロセス・ホームまたはコンカレント要求マネージャを使用します。
ゲートウェイ・モデルの支払システムについて、Oracle Paymentsは、金融業界でクレジット・カード取引に使用される次の処理モデルをサポートしています。
端末ベースの業者になるか、ホスト・ベースの業者になるかの選択は、一般的に、ビジネス・タイプ、1日当りの取引件数、および支払ゲートウェイでサポートされているモデルによって決定されます。選択する処理モデルは、精算操作の実行方法に影響を与えます。端末ベースの業者モデルの場合、精算バッチ操作を定期的に実行する必要があります。詳細は、登録時に取得銀行にお問い合せください。
Oracle Paymentsでは、次のように、クレジット・カード、購買カードおよび暗証番号不要のデビット・カードについて2つの支払処理モデルをサポートしています。
資金取得銀行口座振替は、常にオフラインで行われます。
オンラインで処理できる操作のタイプは、選択した支払システム・タイプ（ゲートウェイ・モデルまたはプロセッサ・モデル）、および操作モデル（ホスト・ベースまたは端末ベース）によって異なります。
プロセッサ・モデル支払システムの場合、承認操作はオンラインで行う必要があり、精算操作はオフラインで行われます。ゲートウェイ支払システムの場合、承認と取得の両方の操作をオンラインで行うことができます。
オンライン支払処理は、取引が支払システムのプロセッサにただちに転送されるモデルです。支払システムからの結果は、ソース製品にただちに戻されます。オンライン取引は、クレジット・カード、購買カードおよび暗証番号不要のデビット・カードでサポートされています。オンライン検証取引は、電子送金でサポートされています。
オフライン支払処理は、取引が支払システムにただちに転送されないモデルです。ソース製品が予定モードで取引を発行したとき、または支払が以前の日付の場合、支払情報はOracle Paymentsデータベースに保存され、後で支払システムに送信されます。
オフラインの方法では、定期的にオフライン取引を発行するコンカレント・プログラムが使用されます。このプログラムは、保存されている取引をブラウズし、支払システムに取引を送信し、ソース製品に更新内容を送信します。
不正なクレジット・カード支払の数は増え続け、それに伴う銀行や業者の損失も増え続けています。したがって、不正検出の改善が必要不可欠です。
Oracle Paymentsには、クレジット・カード取引および購買カード取引に対するリスク管理機能が用意されています。多数のビルトイン・リスク要因が組み込まれ、リスク計算算式およびリスクしきいを調整する機能があります。
リスク要因には、第三者支払人が支払を実行しようとしたときに、第一者受取人が不正のリスクを評価するために使用するあらゆる情報が含まれます。リスク要因の例には、所在地検証、購入時刻および支払金額などがあります。これらのリスク要因を第一者受取人それぞれに対して構成できます。
リスク管理機能を使用すると、第一者受取人は、取引のオンライン処理に伴うリスクを管理できます。また、ビジネスによって、事前定義リスク要因をいくつか指定して、顧客の識別情報を検証し、保護環境で顧客の信用評価とリスク評価を査定できます。
第一者受取人は、リスク要因を算式として様々な重み付けと関連付けることができ、ビジネス・モデルに基づいて、Oracle Paymentsで任意の数のリスク算式を定義できます。ソース製品は、承認の要求時に、リスク査定に使用する算式を指定できます。ソース製品がリスク算式を指定して承認を要求すると、Oracle Paymentsはリスクを評価し、同時に承認要求を支払システムに送信します。支払システムからの応答取得後、承認コードとリスク・スコアの両方をソース製品に戻します。この時点で、ソース製品は取引を続行して精算を実施するか、または取引を中止するかを決定します。
または、リスクAPIを承認APIとは別にコールできます。リスクAPIを単独で使用すると、業者はリスクを最初に評価できます。リスク・スコアによっては、第一者受取人が、支払システムに承認を発行して取引手数料を支払う必要がないと判断する場合があります。ソース製品がリスクAPIを単独でコールする場合、Oracle PaymentsはAVS（所在地検証システム）に関連付けられたリスク・スコアを評価できないことに注意してください。Oracle Paymentsは、承認要求時に支払システムから直接AVSコードを取得します。このような状況で承認要求が送信されない場合、Oracle Paymentsは支払システムからAVSコードを取得できないため、AVSに関連付けられたリスク・スコアを評価できません。
リスク管理は、不正な取引を処理するための手動操作による間接費の削減、および銀行からのチャージバックなどの費用を要するペナルティの回避に役立ちます。
注意: Oracle Paymentsでは、暗証番号不要のデビット・カードまたは銀行口座振替取引に対するリスク管理はサポートされていません。
次に、リスク管理コンポーネントに付属の基本的なリスク要因を示します。これらのリスク要因は受取人ごとに構成できます。
支払金額限度は、支払要求に含まれる金額です。この金額はビジネスごとに異なり、ビジネス・モデルに基づいて、リスク要因スコアを様々な金額範囲について構成できます。
購入時刻は、顧客による支払要求が行われる時刻です。サイト管理者は、支払要求のリスクが高くなる時間帯を定義でき、各時間帯にリスク要因スコアを割り当てることができます。
出荷先/請求先所在地は、支払要求の出荷先所在地と請求先所在地を照合するために使用されます。この2つの所在地が一致しない場合、支払要求は高リスクであるとみなされます。
リスクのある支払手段は、各受取人によってリスクがあるとみなされる支払手段（例: クレジット・カード、銀行口座）のリストです。これらには、以前に顧客が使用し、不正またはチャージバックが発生した手段が含まれます。このようなリストは、受取人が内部的に生成するか、または他のソースから取得できます。これらの手段が支払要求で再使用されると、受取人は、不正またはチャージバックの被害を再度受ける可能性があります。リスク管理機能は、リスクのある手段のリポジトリを検索することによって、リスクのある支払手段が使用されているかどうかを処理中に検出できます。支払に使用されている手段がリポジトリ内にある場合、その支払は高リスクの支払であるとみなされます。データベースに対するリスクのある手段のリストの追加および削除は、高リスク手段アップロード・ユーティリティによって実行されます。
取引金額は、指定した期間内に同じ手段を使用して顧客が行う支払の合計金額です。期間はユーザーが設定します。これは、支払金額限度リスク要因に関係します。顧客は比較的少額の支払を行う場合がありますが、この金額は、支払金額限度リスク要因ではリスクと判断されず、取引金額リスク要因ではリスクと判断される可能性があります。取引金額リスク要因は、一定期間の支払の合計金額を集計し、その金額でリスクを判断します。一定期間の支払の合計件数は、支払履歴を検索して確認できます。サイト管理者は、期間と取引金額を設定できます。このリスク要因の評価では、支払合計金額が一定期間内の取引金額を超えた場合、その支払は高リスクの支払であるとみなされます。
支払履歴は、支払要求に関係する支払人の信頼性を追跡します。支払人の支払履歴が長期間良好である場合、この支払人が要求した支払は低リスクの支払であるとみなされます。
所在地検証サービス（AVS）チェックは、クレジット・カード・ネットワークから戻されるAVSコードに関係するリスクです。所在地検証サービスは、請求先所在地または出荷先所在地を発行銀行がカード所有者について保守している所在地と照合するために、MasterCard社およびVisa社のクレジット・カード・ネットワークによって提供されています。Oracle Paymentsは、支払取引情報とともに所在地および郵便番号情報を指定して支払システムをコールすることで、承認要求時に所在地検証を実行します。この結果、支払システムは承認を実行し、同時に、様々なAVSコードをOracle Paymentsに戻します。完全な所在地照合、郵便番号照合、番地照合などに基づいて、様々な種類のAVSコードが戻されます。サイト管理者は、支払システムから戻されるすべてのAVSコードおよびそれに対応するリスク要因スコアを構成できます。このサービスは、米国でのみ提供されます。
購入頻度は、ある支払手段の使用の短期間における突然の増加を追跡します。支払要求内の特定の支払手段について、構成された期間の使用頻度が設定値を超えた場合、その支払要求は高リスクの支払であるとみなされます。
Oracle PaymentsとOracle Receivablesの両方をインストールおよび登録している場合は、その他のリスク要因を使用できます。これらのリスク要因はOracle Paymentsで設定され、その値はOracle Receivablesで設定されます。Oracle Receivablesでは、信用評価やリスク評価など、顧客アカウントに関するクレジット管理情報が保存されます。次に、リスク分析で使用されるリスク要因を示します。
与信限度は、顧客のアカウントに関連付けられている包括与信限度です。顧客に未処理の残高があり、その顧客の支払合計金額が包括与信限度を超えている場合、支払は高リスクの支払になります。包括与信限度はビジネスごとに異なります。このリスク要因は、Oracle Receivablesを使用して、包括与信限度として顧客レベルまたはサイト・レベルで設定できます。
取引与信限度は、顧客のアカウントに関連付けられている取引ごとの与信限度です。支払要求が取引与信限度を超えると、リスクのある支払になります。取引与信限度はビジネスごとに異なります。このリスク要因は、Oracle Receivablesを使用して、顧客レベルまたはサイト・レベルで設定できます。
信用評価は、受取人がその顧客に関する融資条件を効率的に管理できる情報です。オンライン融資または新規顧客による多額の購入の評価に有効です。信用評価はユーザー定義のフィールドで、情報はOracle Receivablesから取得できます。受取人は、リスク・スコアを信用評価に関連付けます。高いリスク・スコアは、その顧客への商品またはサービスの販売にリスクがあることを示します。
リスク・コードは、Oracle Receivablesのユーザー定義のリスク査定フィールドです。オンライン融資または新規顧客に対する多額の購入の評価に有効です。情報はOracle Receivablesから入手できます。受取人は、すべてのリスク・コードにリスク・スコアを関連付けます。高いリスク・スコアは、その顧客への商品またはサービスの販売にリスクがあることを示します。
Oracle Paymentsは、ソース製品から資金取得支払取引を受け入れ、適切な支払システム・アカウントと資金取得支払プロファイルを使用して、適切な支払システムにルーティングします。各受取人は、独自の優先度のセットを指定した独自のルーティング・ルール・セットを設定できます。
各ルーティング・ルールは、次のコンポーネントで構成されます。
基本ルール情報: この情報は、支払取引に適用可能なすべてのルールを選択し、ランク付けするために使用されます。基本ルール情報は、ルール名と支払方法で構成されます。
宛先情報: 宛先情報では、支払取引のルーティング先の支払システムとその送信方法が指定されます。宛先情報は、支払システム・アカウントと資金取得プロセス・プロファイルで構成されます。
ルーティング・ルール条件: ルールが支払取引に適用可能になる条件が指定されます。ルール条件は、条件に対する基準（金額、通貨、組織ID、カード・タイプ、カード番号、銀行ルーティング番号など）、基準に関連する演算子の種類、および基準の値で構成されます。1つのルーティング・ルールに対して複数のルール条件を定義できます。
支払取引のルーティングは、Oracle Payments管理者がOracle Paymentsユーザー・インタフェースで設定した一連のルーティング・ルールに基づいています。ルーティング・エンジンによって、適切な支払システム・アカウントと資金取得プロセス・プロファイルが検索され、これらを使用して、次の順序で支払システムが検索されます。
ルーティング・エンジンは、支払要求で指定された受取人と支払方法に関連付けられているルールを取得します。
優先度が最も高いルーティング・ルールが最初に評価されます。取引内の値がルーティング・ルールで指定された条件と一致する場合、要求は、指定の支払システム・アカウントと資金取得プロセス・プロファイルを使用して、対応する支払システムにルーティングされます。
要求内の値が、指定された条件と一致しない場合は、次に優先度の高いルーティング・ルールが評価されます。
支払要求の値が、指定されたいずれの条件とも一致しない場合、取引は、デフォルトの支払システム・アカウントと資金取得プロセス・プロファイルを使用して、デフォルトの支払システムにルーティングされます。
ルーティング・ルールの優先度は管理者が設定します。ルールは、処理時に優先度の順序で評価されます。
Oracle Paymentsでは、クレジット・カード、購買カードおよび銀行口座振替がサポートされます。使用可能な支払方法は、使用する支払システムによって異なります。
受取人およびビジネスは、そのビジネス・ルールと使用可能な支払方法に基づいて、Oracle Paymentsがルーティング・ルールを使用して支払システムに取引をルーティングする方法をカスタマイズできます。次に例を示します。
あるビジネスでは、すべての電子支払取引を単一の支払システム（支払システムA）に送信します。
あるビジネスでは、すべての少額（マイクロペイメント）取引を支払システムAに、すべてのクレジット・カード取引を支払システムBに送信します。
あるビジネスでは、$10未満のすべての銀行口座振替を支払システムAに、他のすべての取引を支払システムBに送信します。
あるビジネスでは、USドルを使用したすべての取引を支払システムAに、他の通貨を使用したすべての取引を支払システムBに送信します。
ルーティング・ルール条件によって、ルールが支払取引に適用可能かどうかが判別されます。ルールには複数のルール条件を設定できます。ルールを支払取引に適用できるのは、支払取引がそのルールに対する条件をすべて満たす場合のみです。たとえば、受取人は、受注額が500 USドルを超えた場合のすべてのVisaクレジット・カード取引を、支払システムCにルーティングできます。
次の表に、選択した支払手段タイプおよび基準に対する演算子と値フィールドの値を示します。
| 支払手段タイプ | 基準 | 演算子 | 値 |
|---|---|---|---|
| クレジット・カード | カード・イシュア | 等しい、等しくない | 値リストからカード・イシュアを選択します。 |
| クレジット・カード | 通貨 | 等しい、等しくない | 値リストから通貨を選択します。 |
| クレジット・カード | 金額 | より大きい、以上、より小さい、以下 | 値を指定します。 |
| クレジット・カード | カード番号 | 等しい、等しくない | *値を指定します。 |
| 暗証番号不要のデビット・カード | カード・イシュア | 等しい、等しくない | 値リストからカード・イシュアを選択します。 |
| 暗証番号不要のデビット・カード | 通貨 | 等しい、等しくない | 値リストから通貨を選択します。 |
| 暗証番号不要のデビット・カード | 金額 | より大きい、以上、より小さい、以下 | 値を指定します。 |
| 暗証番号不要のデビット・カード | カード番号 | 等しい、等しくない | * 値を指定します。 |
| 銀行口座振替 | 支払人銀行ルーティング番号 | 等しい、等しくない | 値を指定します。 |
| 銀行口座振替 | 通貨 | 等しい、等しくない | 通貨を選択します。 |
| 銀行口座振替 | 金額 | より大きい、以上、より小さい、以下 | 値を指定します。 |
*: 値には、数字、空白、ダッシュおよびワイルドカード文字（%）を使用できます。たとえば、値が4111%の場合は、4111で始まるすべてのカード番号にルーティング・ルールが適用されます。
Oracleでは、取引データから管理要約が直接提供されます。取引レポート（TR）ユーザーは、特定の事業をターゲットとして、すべてのプロセッサ、カード・タイプおよび取引タイプ全体を要約したインディケータを日次、週次または月次ベースで表示できます。
取引レポートを使用すると、あらゆる規模の組織の各マネージャが、クレジット・カードおよび購買カードで取引されているビジネスの状態を日次ベースで把握でき、目標の達成に向けてビジネスを推進する軌道修正を行うことができます。取引レポートは、一貫性のある整合性の高い情報、企業全体の連携および共同の意思決定を企業が実現するのに役立ちます。事前対策のEメール通知システムによって、重要な指標を常時監視する作業負担が軽減されます。取引レポートを通じて、Oracle Paymentsは、取引の処理と問合せの実行など、異なる様々な作業負荷をサポートする環境をパフォーマンスまたはスケーラビリティを低下させることなく提供し、最も単純で最も費用のかからない方法を提供します。
Oracle PaymentsのEメール・プッシュ・システムでは、指定したユーザーにEメール通知を送信する機能が提供されます。この結果、重要な指標を監視する必要性からメールが解放されます。
Oracle Payments日常業務クローズ・ユーザー職責があるユーザーは、コンカレント要求を発行して、Eメール・プッシュ・システムを実行できます。Oracle PaymentsのEメール・プッシュ・システムは、事前に定義したスケジュールでEメールを送信するように構成できます。レポートでは、取引の日次要約が提供されます。最良の結果を得るために、毎日業務の終了時に処理が実行されるようにスケジュールしてください。Eメールの受信者は、EメールIDまたはユーザー名をコンカレント・タスクのパラメータとして提供することによって指定します。ユーザー名には、有効なEメールIDが関連付けられている必要があります。1つの通知に対して複数の受信者を指定するには、EメールIDまたはユーザー名をカンマ（,）で区切ります。
Eメール・プッシュ・システムでは、その日の取引が要約された後、次の情報が受信者に送信されます。
ログインURL
レポートが生成された日付
取引合計数
取引金額合計
承認取引合計数
承認金額合計
決済済取引合計数
取得金額合計
クレジット/差戻し取引合計数
クレジット/差戻し金額合計
クレジット・カード取引合計数
クレジット・カード取引金額合計
購買カード取引合計数
購買カード取引金額合計
Eメール・プッシュ・プログラムのコンカレント要求をスケジュールする手順は、次のとおりです。
Oracle Payments日常業務クローズ・ユーザー職責があるユーザーでSelf Service Applicationsにログインします。
ユーザー名に複数の職責がリンクされている場合は、Oracle Payments日常業務クローズ・ユーザー職責を選択します。
「新規要求の発行」ウィンドウにナビゲートします。
「単一要求」オプションを選択します。
「名称」選択リストから、「IBYプッシュEメール・レポート」を選択します。
受信者のEメール・アドレスを指定します。複数アドレスを指定する場合は、セパレータとしてカンマ（,）を使用します。
スケジュールを定義するには、「スケジュール」をクリックします。
「スケジュール」ウィンドウが表示されます。
スケジュールを定義します。
スケジュールの定義は、可能な限り早く発行できるように単純にすることも、より複雑なスケジュールを使用することもできます。
「発行」をクリックします。
この項では、資金支出プロセスに関連する機能と用語について説明します。
買掛/未払金文書は、支払のためにOracle Paymentsに送信されるソース製品内の取引です。Oracle Payablesでの買掛/未払金文書の例は請求書です。支払プロセスでは、買掛/未払金文書は実際の支払にグループ化されます。
支払は、印刷支払文書または電子伝送を介した、ある個人または組織から別の個人または組織への単一の送金です。
支払プロセスは、Payablesなどのソース製品で請求書などの買掛/未払金文書を支払う必要がある時点から開始します。ソース製品ユーザーは、買掛/未払金文書を支払プロセス要求にグループ化し、要求をOracle Paymentsに発行します。Oracle Payments内では、支払作成プログラムが、発行された買掛/未払金文書を取得して検証し、支払にグループ化した後、支払を検証します。各支払は、1つ以上の買掛/未払金文書で構成されます。次に、「支払指示の作成」プログラムが、支払を支払指図にグループ化し、支払指図を検証します。各支払は、選択した処理のタイプに応じて、印刷される小切手、または単一の電子送金取引を表します。各支払指図は、支払金額やクレジット対象または請求対象の口座など、1つ以上の支払に関連する情報を含む、1つの支払ファイルになります。電子支払の場合、支払ファイルには、金融機関が必要とする形式の支払指図が含まれます。実際に支払を行うには、小切手を印刷するか、外部システムまたは金融機関に支払指図を電子的に伝送します。
次の図は、上位レベルの支払プロセスを示しています。
Oracle Paymentsの資金支出側では、支払方法は買掛/未払金文書の支払属性です。支払方法は、第一者支払人が第三者受取人に対して行う支払の手段を示します。支払方法には、支払方法を買掛/未払金文書に割り当てる方法を決定する検証やルールなど、支払処理の初期段階で使用される他の情報も含まれます。資金支出支払方法の例は、次のとおりです。
支払者が社内で印刷する小切手
印刷のために銀行に外部委託される小切手
ACH（米国）またはBACS（英国）を介した電子送金
銀行振込
Oracle Paymentsは一部の支払方法をシードしますが、ユーザーは独自の支払方法を定義することもできます。
Oracle Payables担当者などのソース製品ユーザーは、請求書などの買掛/未払金文書を入力するときに支払方法を選択する必要があります。ソース製品はOracle Payments設定を使用して、各買掛/未払金文書でデフォルトとなる支払方法を設定し、ユーザーの支払方法の選択肢を制限して、効率的な支払処理が行われるようにします。
支払プロセス・プロファイルは、買掛/未払金文書に割り当てられる支払属性で、Oracle Paymentsによる買掛/未払金文書、支払および支払指図の処理を指定します。支払プロセス・プロファイルには、支払指図フォーマットや伝送の指定など、複数のタイプの情報が含まれます。
ソース製品ユーザーまたはOracle Payments支払管理者は、支払プロセス・プロファイルを買掛/未払金文書に割り当てることができます。有効な支払プロセス・プロファイルの選択は、Oracle Payments設定で作成される支払プロセス・プロファイルの使用ルールによって決定されます。支払プロセス・プロファイルの使用ルールは、支払方法、支払通貨、第一者組織または当方銀行口座に基づくことができます。
支払は、属性の中でも、同じ支払プロセス・プロファイルを持つ買掛/未払金文書から作成されます。支払指図は、属性の中でも、同じ支払プロセス・プロファイルを持つ支払から作成されます。したがって、支払プロセス・プロファイルは、支払プロセスのすべてのステップでOracle Paymentsの動作を指定できます。
支払プロセス・プロファイルの作成時に、印刷支払または電子支払に対する支払処理をプロファイルで管理するかどうかを指定する必要があります。したがって、支払プロセス・プロファイルを使用すると、適切な支払文書の印刷値または支払システムの通信構成を割り当てることができます。また、支払プロセス・プロファイルには、支払指図フォーマット（XMLパブリッシャ・テンプレートに関連付けられます）、および買掛/未払金文書を支払にグループ化し、支払を支払指図にグループするためのルールも含まれます。
支払プロセス・プロファイルと支払方法の関係は、多対多です。たとえば、電子送金などの一般支払方法を1つ定義し、それを米国の自動手形交換所やドイツのEFTなど、特定の複数の支払プロセス・プロファイルにマップできます。または、支払プロセス・プロファイルと1対1でマップされる特定の支払方法を設定することもできます。さらに、複数の支払方法に対して1つの支払プロセス・プロファイルを定義できます。この方法は、複数の支払方法を同じ支払フォーマットで処理できる場合に適しています。たとえば、ドイツ国内プロファイルは、外部委託の小切手およびEFT支払の支払方法を処理できます。
正支払および電子支払処理の場合、支払プロセス・プロファイルは、支払システム、支払システム・アカウントおよび伝送構成にマップされます。
Oracle Paymentsには、一定数の支払プロセス・プロファイルがシードされています。
支払プロセス要求は、Oracle Payments支払サービスのソース製品によって作成される要求です。支払プロセス要求は、買掛/未払金文書の選択処理中にソース製品から発生し、支払対象の1つ以上の買掛/未払金文書が含まれます。また、Oracle Paymentsとソース製品による、要求とオプションの支払処理指図の識別を可能にするための情報も含まれます。ソース製品は、ユーザーの処理またはコンカレント・プログラムを介して支払プロセス要求をOracle Paymentsに発行できます。
支払プロセス要求がOracle Paymentsに発行されると、支払作成プログラムは、買掛/未払金文書を検証し、文書属性と支払プロセス・プロファイルのグループ化ルールに従って買掛/未払金文書を支払にグループ化した後、支払を検証します。
支払グループ化は、「支払プロセス・プロファイルの作成」ページの「支払グループ化」リージョンにあるチェック・ボックスを使用して設定されます。支払グループ化属性の選択は、「支払指示の作成」プログラムの実行時にその支払プロセス・プロファイルが使用された場合、同様の支払グループ化属性の支払のみが支払指図に含まれることを指定します。
支払指図には、支払総計情報とともに1つ以上の支払が含まれ、「支払指示の作成」プログラムの実行によって作成されます。設定に応じて、支払指図を小切手などの支払文書に印刷される支払ファイルに変換することも、処理や支出のために支払システムまたは金融機関に伝送される支払ファイルに変換することもできます。支払指図と支払の間の関係を確認するには、「支払プロセス」を参照してください。
支払システムまたは金融機関に電子送金される各支払指図は、支払ファイルに関連付けられます。この支払ファイルには、支払システムまたは金融機関に支払方法を指示するデータが含まれます。通常、電子送金される支払ファイルには次の情報が含まれます。
行われる支払の数
各支払の金額
第一者支払人および第三者受取人の銀行口座情報
受取人の名前
通常、印刷支払ファイルには次の情報が含まれます。
各支払の金額
小切手の採番方法
受取人の名前
支払処理では、支払システムおよび金融機関に送信する支払ファイルが正しくフォーマットされていることに加え、有効であることを確認することが重要です。これが実施されないと、支払プロセスに要する時間が長くなり、問題解決のために余計な時間と費用がかかります。ストレート・スルー・プロセッシングを達成するために、Oracle Paymentsでは、支払関連の検証が提供されていることを確認できます。
Oracle Paymentsには、サポートされている支払フォーマットにデフォルトで関連付けられているシード検証があります。検証は、新規検証ルールを割り当てることができる柔軟なフレームワークを使用して実装されます。検証のシード・ライブラリ、新しく追加した検証、またはこれらのルールの組合せのいずれを使用することもできます。
さらに、検証ルールの実行時期について選択できます。検証は、支払プロセスの早い段階または遅い段階に割り当てることができます。ルール割当を組み合せて使用することもできます。検証ルール割当は、ビジネス・モデルをサポートするように調整できます。たとえば、支払プロセスの早い段階での検証ルールの割当と実行は、分散支払環境に最も適している場合があります。一方、遅い段階での検証の割当と実行は、支払担当者が検証の失敗を解決できる共有サービス環境に適している場合があります。
シード検証は、次のいずれかの場所で割り当てることができます。
「支払方法の作成」ページ: 資金取得側
「支払方法の作成」ページ: 資金支出側
「フォーマットの作成/更新」ページ
検証は次のカテゴリで構成されます。
事前定義の検証
ユーザー定義の検証
国固有の検証は、特定の国に関連する検証です。特定の国に必要なコードと複数のサブ検証、検証ポイント、および検証が適用される支払フォーマットまたは支払方法（あるいはその両方）に関する追加指定で構成されます。国固有の検証はOracle Paymentsによりシードされており、変更できません。Oracle Paymentsにシードされている国固有の検証のリストは、「国固有の検証」を参照してください。
次の表は、国固有の検証の要素を表しています。
ユーザー定義の検証は、単純な操作に対応する基本的な検証です。たとえば、特定のフィールドの長さが特定の文字制限を超えないことを検証します。これらの検証は、さらに複雑な検証を作成するためのコンポーネント（基本要素）として使用できます。たとえば、次のような条件を検証できます。
フィールドの長さ
フィールドに値が入力されているかどうか
フィールドに数字以外の文字が含まれているかどうか
ユーザー定義の検証の適用例をあげると、たとえば新規支払フォーマットを「書式の作成」設定ページで作成し、新しく作成したフォーマットに検証を割り当てることができます。
注意: ユーザー定義の検証は、国固有の検証と同じポイントで実行されます。検証ポイントの詳細は、国固有の検証の表の要素内にある「検証ポイント」を参照してください。
