ヘッダーをスキップ

Oracle Paymentsインプリメンテーション・ガイド
リリース12
E06000-01
目次へ
目次
前のページへ
前へ
次のページへ
次へ

Oracle Paymentsの理解

資金取得と資金支出に共通の機能

Oracle Paymentsの資金取得側と資金支出側の両方に共通の支払機能は、次のとおりです。

アクセス管理について

アクセス管理は、データの表示または更新(あるいはその両方)におけるユーザー・アクセスを管理できるOracle Paymentsの機能です。主に取引データの保護に使用され、ユーザーのセキュリティ・プロファイルによって管理されます。複数組織に関する権限で管理されるOracle Paymentsのアクセス管理は、複数組織アクセス管理(MOAC)と呼ばれます。MOACはOracle HRMS(人事管理システム)のプロファイルを使用して設定されます。このプロファイルで、ユーザーがアクセス可能な組織または組織の階層を指定します。プロファイルは、ユーザー、職責または他のレベルに割り当てられます。

概要

企業は、パフォーマンスと費用削減を最大化するために、様々な方法でビジネス単位をモデル化します。Oracle Paymentsは、各種の支払モデルをサポートするように構成できます。完全に分散化されたモデル内で動作可能で、この場合は企業内の各組織で独自の財務活動が処理されます。または、企業が共有サービス・センターで財務活動を一元化しようとする場合は、共有サービス・センター・モデルも効率的にサポートできます。

さらに、Oracle Paymentsでは、支払ファクトリ・モデルを使用する企業がサポートされます。支払ファクトリを使用すると、営業単位は独自の買掛管理およびその他の支払管理機能を保守できます。支払ファクトリは、採用企業の銀行業務パートナとの通信および取引を処理します。請求書選択は、Oracle Payablesで単一の営業単位内で実施されます。この結果、支払ファクトリ管理者は、Oracle Paymentsを使用して、異なる営業単位の支払を伝送および精算用の1つの支払ファイルに連結できるため、取引原価を削減できます。

支払機能

支払機能には、ソース製品によって行われる支払または取得される支払のタイプがあります。各買掛/未払金文書に支払機能が設定されます。たとえば、Oracle Payablesでは、仕入先などに支払を行う支払機能がサポートされます。様々なアプリケーションに様々な支払機能があります。Oracle Paymentsでは、各ユーザーを特定の支払機能に制限できます。

複数組織アクセス管理(MOAC)

Oracle Paymentsでは、複数組織アクセス管理(MOAC)がサポートされます。MOACはアクセス管理のサブ機能で、Oracle Applicationsの単一インストール内で、複数組織とその組織の関係を定義できます。これらの組織には、営業単位、ビジネス・グループ、法的エンティティ、会計帳簿または在庫組織などがあります。

MOACの主な利点は、様々な職責にログインすることなく、異なる営業単位内の文書に関する処理を実行できることです。データ・セキュリティは、セキュリティ・プロファイルを使用して保守されます。セキュリティ・プロファイルは、特定のユーザーにデータ・アクセス権限が付与されている営業単位のリストに対して定義されます。

読取り専用ページのアクセス管理

読取り専用ページでは、アクセス権限がある文書または支払のみを表示できます。つまり、表示されるデータは、アクセス権限があるデータです。

逆に言うと、アクセス権限のない組織または支払機能に関する文書または支払を表示することはできません。ただし、支払プロセス要求、支払指図および資金精算バッチには、複数組織のデータが含まれる場合があり、組織固有ではありません。このような場合、要求、指図または精算バッチ内のデータを所有している組織に対するアクセス権限がある場合は、これらを参照できます。しかし、その要求、指図または精算バッチ内で表示できる取引データは、アクセス権限がある組織が所有しているデータのみです。

処理ページのアクセス管理

処理ページとは、買掛/未払金文書、支払、支払プロセス要求、支払指図、資金精算取引または精算バッチに関するあらゆる種類の処理を実行するページです。小切手の印刷、検証エラーの修正、資金取得および資金支出ダッシュボードにおけるその他の処理の実行などがあります。エンティティに関する処理を実行できるのは、エンティティ内の全データに対するアクセス権限がある場合のみです。たとえば、支払指図に組織1と組織2に対する支払が含まれていて、組織1に対するアクセス権限のみがある場合、その支払指図に対する処理ページにはアクセスできません。つまり、オブジェクト内のデータに対して部分アクセス権限しかない場合、そのオブジェクトにはアクセスできません。この場合、オブジェクトに対するフル・アクセス権限がないことを示すメッセージが表示されます。

支出システム・オプション設定ページのアクセス管理

支出システム・オプション設定ページでは、アクセス権限がある組織に対する組織レベルのシステム・オプションのみを表示および更新できます。Oracle Paymentsによって、表示および更新できる内容が、アクセス権限がある内容のみに制限されます。

他の全設定ページのアクセス管理

他のすべての設定ページでは、アクセス管理に関係なく、表示および更新できる内容は制限されません。

支払プロセス・コンカレント・プログラムのアクセス管理

次のコンカレント・プログラムは、組織に対するアクセス権限によって制限されます。

Oracle Payments APIについて

Oracle Paymentsには、支払処理について既存または新規のアプリケーションとOracle Paymentsの統合を簡素化するために、2種類のAPIが用意されています。

Oracle Paymentsサーブレットについて

Oracle Paymentsは次のサーブレットで構成されています。

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の設定ページで表示できます。

伝送構成

各伝送プロトコルには、値を必要とするパラメータがあります。パラメータに定義される値によって、伝送プロトコルの伝送構成が構成されます。たとえば、支払システムPaymentechには、特にソケットIPアドレスXとソケット・ポート番号Yが必要です。XYと他の値によって、特定の伝送プロトコル用の伝送構成Aが表されます。

Oracle Paymentsのセキュリティについて

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のアーキテクチャを使用すると、ファイアウォールの外側のマシンに支払システム・サーブレットをインストールできます。Oracle Payments(またはそのコンポーネント)またはソース製品のいずれかを分散環境にインストールしている場合は、Oracle Paymentsと支払システム・コンポーネントの間にSSLを構成することをお薦めします。Oracle Walletを作成すると、エンジン(この場合はサーブレットのクライアント)の認証をサポートするための証明書と資格証明の情報を、サーブレットを実行しているサーバーごとに格納できます。Walletの場所とパスワードはFNDプロファイルを使用して指定できます。サーブレットが実行されているサーバーを、(エンジン側の)クライアント証明書を要求するように構成できます。Oracle Paymentsは、Oracle Walletから証明書を取得し、認証のためにサーバーに送信します。また、支払システムの基本認証がサーブレットによってサポートされます。

これらのセキュリティ機能は、データおよびOracle Paymentsサービスに対する無許可アクセスから保護するために使用することをお薦めします。Oracle iAS Webサーバー(Apacheサーバー)には、サーバー、リスナーおよびサーブレットの保護に使用できる数種類の認証が用意されています。

ファイアウォール保護

Oracle Paymentsと支払システム・サーブレットは、ファイアウォールの内側にあるマシンにインストールすることをお薦めします。

Secure Socket Layer

Oracle Payments(またはそのコンポーネント)またはソース製品のいずれかが分散環境にインストールされている場合は、Oracle Paymentsと支払システム・コンポーネント間でSSL通信を使用可能にすることをお薦めします。

支払システムの基本認証

Oracle Paymentsと支払システム・サーブレット間の基本認証に関するセキュリティを設定するために、Oracle Paymentsの設定ユーザー・インタフェースとApacheサーバー管理ツールの両方でいくつかのタスクを実行する必要があります。特定の支払システム用にOracle Paymentsを構成すると同時に、支払システムの構成画面で、支払システムにユーザー名とパスワードを割り当てる必要があります。また、同じユーザー名とパスワードを、支払システム・サーブレットを実行するApacheサーバーで割り当てる必要があります。

Apacheサーバーで基本認証を設定する方法の詳細は、Apacheサーバーのマニュアルを参照してください。

IPアドレスの制限

業者のユーザー名とパスワードを使用する以外に、IPアドレス制限によって、Oracle Paymentsと支払システムへのアクセスを制限できます。Apacheサーバーの機能であるIPアドレス制限を使用すると、次のいずれかまたは両方のパラメータを指定できます。

信頼されたリストのマシンからの要求の場合は、Oracle Paymentsが要求された取引を処理します。信頼されていないリストのマシンからの要求の場合は、Apacheサーバーが要求を拒否し、Oracle Paymentsで要求が処理されないようにします。

IPアドレス制限によって、すべての操作に対する信頼されていないマシンからのアクセスを制限できます。

信頼されたホストの指定方法など、IPアドレス制限に関する詳細は、Apacheサーバーのマニュアルを参照してください。

その他のセキュリティ関連の情報

関連項目

Oracle Walletの詳細は、『Oracle Applicationsシステム管理者ガイド - セキュリティ』を参照してください。

資金取得について

この項では、資金取得プロセスに関連する機能と用語について説明します。

資金取得プロセス・プロファイルについて

資金取得側の資金取得プロセス・プロファイルは、Oracle Paymentsに支払システムとの通信方法を指示する情報が含まれた設計図です。次に示す資金取得管理プロセスの各ステップに関する情報が含まれています。

資金取得側の資金取得プロセス・プロファイルの役割は、資金支出側の支払プロセス・プロファイルと同じです。資金取得プロセス・プロファイルは、前述のように、すべての資金取得操作の動作をアクセス管理するために定義されます。ただし、支払プロセス・プロファイルと異なり、資金取得プロセス・プロファイルは常に、受取人設定時に作成されるルーティング・ルールから導出されます。

また、資金取得プロセス・プロファイルでは、取引の処理に使用される支払システム・アカウントも指定されます。

支払方法について(資金取得)

Oracle Paymentsの資金取得側での支払方法は、第三者支払人が第一者受取人への支払送金のために選択する手段です。たとえば、ある顧客は製品またはサービスの支払を採用企業に送金します。Oracle Paymentsは、自動資金取得処理について、次の支払方法をサポートしています。

Oracle Paymentsを使用すると、次のように、資金取得支払方法を柔軟に設定できます。

受取人について

Oracle Paymentsでは、受取人は、顧客から資金を回収する第一者エンティティを表します(資金取得支払の場合)。また、受取人には、支払システムとの間に、支払システムが受取人に関する取引を処理するというビジネス関係があります。

Oracle Paymentsでは、資金取得について複数の受取人を設定できます。複数の受取人を設定できる理由は、たとえば、1つの組織内の異なるビジネス単位または法的エンティティが別々の支払システムによって取引を処理する場合や、支払システムとの個別の関係を使用する場合があるためです。

Oracle Paymentsで受取人を作成する際は、いくつかの情報を指定する必要があります。

他のOracle Applicationsとの統合

Oracle Paymentsは、企業全体の支払処理を提供するために他のOracle Applicationsと統合されています。様々なソース製品が、取引要求を処理のためにOracle Paymentsに送信します。Oracle Paymentsがない場合、これらの各アプリケーションは、支払システムに対する独自の統合を作成する必要があります。Oracle Paymentsは、Concord EFSnet、First Data Northなどの支払システム、および他の各国固有または地域固有の支払システムに対する単一のソースを提供することによって、統合作業を不要にします。

Oracle Paymentsと他のOracle Applicationsを使用した支払処理フローの例

  1. セールス・アプリケーション(例: iStoreまたはTeleSales): 顧客が製品を購入し、クレジット・カードで支払うことにします。セールス・アプリケーションはオーダーを発行します。

  2. Order CaptureまたはOrder Management: Order CaptureおよびOrder Managementが受注を処理します。両方のアプリケーションがOracle Paymentsを使用して、クレジット・カード番号が有効であるかどうかを検証し、受注金額を承認します。また、承認の一部として、一部のリスク評価も実行できます。

  3. Oracle Receivables: 受注が出荷されると、取引情報がOracle Receivablesに渡され、請求が行われます。

  4. Oracle Collections: 支払の期限を超過し、コール・センターで資金支出回収試行を開始すると、Oracle Collectionsは、Oracle Paymentsを使用して、クレジット・カード取引を承認し、精算します。

    Oracle PaymentsとOracle Applicationsの統合

    本文の説明内容に関するイメージ

クレジット・カード取引について

資金取得支払のうち、Oracle Paymentsはクレジット・カード取引、暗証番号不要のデビット・カード取引、購買カード取引およびEFT取引を処理します。この項では、一般的なクレジット・カード取引のフローについて説明します。

従来のクレジット・カード取引

従来のクレジット・カード取引の処理には、第三者支払人、第一者受取人、発行銀行、取得銀行、支払プロセッサ、およびオプションで支払ゲートウェイが関係します。

クレジット・カード取引は、承認と精算の2つのフェーズで構成されます。一般的なフローは、次のように行われます。

音声承認

クレジット・カード処理ネットワークは、取引を完了するために業者がカード所有者の発行銀行に電話する必要があることを示す照会メッセージ付きの取引を拒否する場合があります。このような場合、支払情報は電話で発行されます。取引が承認されると、業者には取引の承認コードが付与されます。この音声承認に対するOracle Paymentsによる後続取引(取得、無効など)を容易にするために、Oracle Paymentsでは、ゲートウェイ・モデルおよびプロセッサ・モデルの支払システムに対する音声承認サポートが提供されています。

購買カードについて

購買カードは、組織が従業員に発行するクレジット・カードの一種です。通常、購買カードは、企業の商品およびサービスを購入するために従業員が使用します。支払は、企業の購買担当がカード・イシュアに対して行います。

業者(第一者受取人)にとっての購買カードの利点

購買担当(第三者支払人)にとっての購買カードの利点

購買カード・データ・レベル

購買カードでは、3つのレベルのデータを取得し、業者が支払システムを介して購買担当組織に送信できます。3つのレベルは次のとおりです。

レベルI:

レベルIの取引データは、基本的なデータのみで構成されます。標準的なクレジット・カード取引では、レベルIデータをプロセッサに提供します。業者がレベルIデータのみを渡す場合、購買担当は購買カードの利用によって特別な利益を得ることはできません。

レベルII:

レベルII取引データは、レベルIデータ以外に、税金金額やオーダー番号などのデータで構成されます。

レベルIII:

レベル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取引で使用される第三者支払人の銀行口座を検証します。EFTオンライン検証サービスでは、第三者支払人の銀行口座手段が存在し、不正のアラートがないことが保証されます。電子送金取引は、取引の完了に1営業日から2営業日が必要であるため、リアルタイムでは行われません。したがって、銀行口座がまだ開いており、十分な資金があることは保証できません。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では、暗証番号不要のデビット・カードまたは銀行口座振替取引に対するリスク管理はサポートされていません。

Oracle Paymentsに付属のリスク要因

次に、リスク管理コンポーネントに付属の基本的なリスク要因を示します。これらのリスク要因は受取人ごとに構成できます。

Oracle Receivablesのリスク要因

Oracle PaymentsとOracle Receivablesの両方をインストールおよび登録している場合は、その他のリスク要因を使用できます。これらのリスク要因はOracle Paymentsで設定され、その値はOracle Receivablesで設定されます。Oracle Receivablesでは、信用評価やリスク評価など、顧客アカウントに関するクレジット管理情報が保存されます。次に、リスク分析で使用されるリスク要因を示します。

Oracle Paymentsのルーティングと処理

Oracle Paymentsは、ソース製品から資金取得支払取引を受け入れ、適切な支払システム・アカウントと資金取得支払プロファイルを使用して、適切な支払システムにルーティングします。各受取人は、独自の優先度のセットを指定した独自のルーティング・ルール・セットを設定できます。

ルーティング・ルールの構成内容

各ルーティング・ルールは、次のコンポーネントで構成されます。

ルーティングの機能

支払取引のルーティングは、Oracle Payments管理者がOracle Paymentsユーザー・インタフェースで設定した一連のルーティング・ルールに基づいています。ルーティング・エンジンによって、適切な支払システム・アカウントと資金取得プロセス・プロファイルが検索され、これらを使用して、次の順序で支払システムが検索されます。

  1. ルーティング・エンジンは、支払要求で指定された受取人と支払方法に関連付けられているルールを取得します。

  2. 優先度が最も高いルーティング・ルールが最初に評価されます。取引内の値がルーティング・ルールで指定された条件と一致する場合、要求は、指定の支払システム・アカウントと資金取得プロセス・プロファイルを使用して、対応する支払システムにルーティングされます。

  3. 要求内の値が、指定された条件と一致しない場合は、次に優先度の高いルーティング・ルールが評価されます。

  4. 支払要求の値が、指定されたいずれの条件とも一致しない場合、取引は、デフォルトの支払システム・アカウントと資金取得プロセス・プロファイルを使用して、デフォルトの支払システムにルーティングされます。

ルーティング・ルールの優先度は管理者が設定します。ルールは、処理時に優先度の順序で評価されます。

Oracle Paymentsでは、クレジット・カード、購買カードおよび銀行口座振替がサポートされます。使用可能な支払方法は、使用する支払システムによって異なります。

受取人およびビジネスは、そのビジネス・ルールと使用可能な支払方法に基づいて、Oracle Paymentsがルーティング・ルールを使用して支払システムに取引をルーティングする方法をカスタマイズできます。次に例を示します。

ルーティング・ルール条件

ルーティング・ルール条件によって、ルールが支払取引に適用可能かどうかが判別されます。ルールには複数のルール条件を設定できます。ルールを支払取引に適用できるのは、支払取引がそのルールに対する条件をすべて満たす場合のみです。たとえば、受取人は、受注額が500 USドルを超えた場合のすべてのVisaクレジット・カード取引を、支払システムCにルーティングできます。

次の表に、選択した支払手段タイプおよび基準に対する演算子と値フィールドの値を示します。

支払手段タイプ 基準 演算子
クレジット・カードカード・イシュア等しい、等しくない値リストからカード・イシュアを選択します。
クレジット・カード通貨等しい、等しくない値リストから通貨を選択します。
クレジット・カード金額より大きい、以上、より小さい、以下値を指定します。
クレジット・カードカード番号等しい、等しくない*値を指定します。
暗証番号不要のデビット・カードカード・イシュア等しい、等しくない値リストからカード・イシュアを選択します。
暗証番号不要のデビット・カード通貨等しい、等しくない値リストから通貨を選択します。
暗証番号不要のデビット・カード金額より大きい、以上、より小さい、以下値を指定します。
暗証番号不要のデビット・カードカード番号等しい、等しくない* 値を指定します。
銀行口座振替支払人銀行ルーティング番号等しい、等しくない値を指定します。
銀行口座振替通貨等しい、等しくない通貨を選択します。
銀行口座振替金額より大きい、以上、より小さい、以下値を指定します。

*: 値には、数字、空白、ダッシュおよびワイルドカード文字(%)を使用できます。たとえば、値が4111%の場合は、4111で始まるすべてのカード番号にルーティング・ルールが適用されます。

取引レポートについて

Oracleでは、取引データから管理要約が直接提供されます。取引レポート(TR)ユーザーは、特定の事業をターゲットとして、すべてのプロセッサ、カード・タイプおよび取引タイプ全体を要約したインディケータを日次、週次または月次ベースで表示できます。

取引レポートを使用すると、あらゆる規模の組織の各マネージャが、クレジット・カードおよび購買カードで取引されているビジネスの状態を日次ベースで把握でき、目標の達成に向けてビジネスを推進する軌道修正を行うことができます。取引レポートは、一貫性のある整合性の高い情報、企業全体の連携および共同の意思決定を企業が実現するのに役立ちます。事前対策のEメール通知システムによって、重要な指標を常時監視する作業負担が軽減されます。取引レポートを通じて、Oracle Paymentsは、取引の処理と問合せの実行など、異なる様々な作業負荷をサポートする環境をパフォーマンスまたはスケーラビリティを低下させることなく提供し、最も単純で最も費用のかからない方法を提供します。

Eメール・プッシュ・システムの機能

Oracle PaymentsのEメール・プッシュ・システムでは、指定したユーザーにEメール通知を送信する機能が提供されます。この結果、重要な指標を監視する必要性からメールが解放されます。

Oracle Payments日常業務クローズ・ユーザー職責があるユーザーは、コンカレント要求を発行して、Eメール・プッシュ・システムを実行できます。Oracle PaymentsのEメール・プッシュ・システムは、事前に定義したスケジュールでEメールを送信するように構成できます。レポートでは、取引の日次要約が提供されます。最良の結果を得るために、毎日業務の終了時に処理が実行されるようにスケジュールしてください。Eメールの受信者は、EメールIDまたはユーザー名をコンカレント・タスクのパラメータとして提供することによって指定します。ユーザー名には、有効なEメールIDが関連付けられている必要があります。1つの通知に対して複数の受信者を指定するには、EメールIDまたはユーザー名をカンマ(,)で区切ります。

Eメール・プッシュ・システムでは、その日の取引が要約された後、次の情報が受信者に送信されます。

Eメール・プッシュ・プログラムのスケジューリング

Eメール・プッシュ・プログラムのコンカレント要求をスケジュールする手順は、次のとおりです。

  1. Oracle Payments日常業務クローズ・ユーザー職責があるユーザーでSelf Service Applicationsにログインします。

    ユーザー名に複数の職責がリンクされている場合は、Oracle Payments日常業務クローズ・ユーザー職責を選択します。

  2. 「新規要求の発行」ウィンドウにナビゲートします。

  3. 「単一要求」オプションを選択します。

  4. 「名称」選択リストから、「IBYプッシュEメール・レポート」を選択します。

  5. 受信者のEメール・アドレスを指定します。複数アドレスを指定する場合は、セパレータとしてカンマ(,)を使用します。

  6. スケジュールを定義するには、「スケジュール」をクリックします。

    「スケジュール」ウィンドウが表示されます。

  7. スケジュールを定義します。

    スケジュールの定義は、可能な限り早く発行できるように単純にすることも、より複雑なスケジュールを使用することもできます。

  8. 「発行」をクリックします。

資金支出について

この項では、資金支出プロセスに関連する機能と用語について説明します。

買掛/未払金文書について

買掛/未払金文書は、支払のためにOracle Paymentsに送信されるソース製品内の取引です。Oracle Payablesでの買掛/未払金文書の例は請求書です。支払プロセスでは、買掛/未払金文書は実際の支払にグループ化されます。

支払について

支払は、印刷支払文書または電子伝送を介した、ある個人または組織から別の個人または組織への単一の送金です。

支払プロセス

支払プロセスは、Payablesなどのソース製品で請求書などの買掛/未払金文書を支払う必要がある時点から開始します。ソース製品ユーザーは、買掛/未払金文書を支払プロセス要求にグループ化し、要求をOracle Paymentsに発行します。Oracle Payments内では、支払作成プログラムが、発行された買掛/未払金文書を取得して検証し、支払にグループ化した後、支払を検証します。各支払は、1つ以上の買掛/未払金文書で構成されます。次に、「支払指示の作成」プログラムが、支払を支払指図にグループ化し、支払指図を検証します。各支払は、選択した処理のタイプに応じて、印刷される小切手、または単一の電子送金取引を表します。各支払指図は、支払金額やクレジット対象または請求対象の口座など、1つ以上の支払に関連する情報を含む、1つの支払ファイルになります。電子支払の場合、支払ファイルには、金融機関が必要とする形式の支払指図が含まれます。実際に支払を行うには、小切手を印刷するか、外部システムまたは金融機関に支払指図を電子的に伝送します。

次の図は、上位レベルの支払プロセスを示しています。

支払プロセス

本文の説明内容に関するイメージ

支払方法について(資金支出)

Oracle Paymentsの資金支出側では、支払方法は買掛/未払金文書の支払属性です。支払方法は、第一者支払人が第三者受取人に対して行う支払の手段を示します。支払方法には、支払方法を買掛/未払金文書に割り当てる方法を決定する検証やルールなど、支払処理の初期段階で使用される他の情報も含まれます。資金支出支払方法の例は、次のとおりです。

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にシードされている国固有の検証のリストは、「国固有の検証」を参照してください。

次の表は、国固有の検証の要素を表しています。

国固有の検証の要素
要素 説明
コード検証用の内部コード。
サブ検証特定の検証で実行されるすべての検証。
検証ポイント 支払プロセス内で検証が実行されるポイント。検証は、支払プロセス内の次のポイントで実行されます。
  • ソース製品の文書レベル: 検証は、ソース製品で文書が作成される間のプロセスの早い段階で実行されます。ソース製品ユーザーによって、たとえばPayablesで請求書を入力するときに実行されます。



    ソース製品の文書レベルで実行される検証の例: 請求書の支払方法への検証の割当



  • Oracle Paymentsの文書レベル: 検証は、支払作成プログラムにより、文書が支払にグループ化されるときのプロセスの遅い段階で自動的に実行されます。



    Oracle Paymentsの文書レベルで実行される検証の例: 支払フォーマットへの検証の割当



  • Oracle Paymentsの支払レベル: 検証は、支払作成プログラムにより、文書が支払にグループ化されるときのプロセスの遅い段階で自動的に実行されます。この検証は、支払金額などのフィールドに検証が設定されている場合に実行されます。



    Oracle Paymentsの支払レベルで実行される検証の例: 支払の支払金額への検証の割当



  • Oracle Paymentsの支払指図レベル: 検証は、「支払指示の作成」プログラムにより、支払が支払指図にグループ化されるときのプロセスの遅い段階で自動的に実行されます。この検証は、支払指図合計金額などのフィールドに検証が設定されている場合に実行されます。



    Oracle Paymentsの支払指図レベルで実行される検証の例: 支払指図の支払金額合計への検証の割当

検証が適用されるエンティティ検証がリンクされるエンティティ。Oracle Paymentsでは、ユーザー・インタフェースを使用して、どの支払方法または支払フォーマットでどの検証を実行するかを制御できます。適用可能な特定のリンクがデフォルトでシードされています。ただし、これらの適用は変更できます。たとえば、特定の支払フォーマットにリンクされている特定の検証を、別の支払フォーマットにも適用するように指定できます。

ユーザー定義の検証

ユーザー定義の検証は、単純な操作に対応する基本的な検証です。たとえば、特定のフィールドの長さが特定の文字制限を超えないことを検証します。これらの検証は、さらに複雑な検証を作成するためのコンポーネント(基本要素)として使用できます。たとえば、次のような条件を検証できます。

ユーザー定義の検証の適用例をあげると、たとえば新規支払フォーマットを「書式の作成」設定ページで作成し、新しく作成したフォーマットに検証を割り当てることができます。

注意: ユーザー定義の検証は、国固有の検証と同じポイントで実行されます。検証ポイントの詳細は、国固有の検証の表の要素内にある「検証ポイント」を参照してください。