リリース12
E06000-01
目次
前へ
次へ
| Oracle Paymentsインプリメンテーション・ガイド リリース12 E06000-01 | 目次 | 前へ | 次へ |
この章では、Oracle Paymentsで使用される公開APIについて説明します。
Oracle Paymentsには、実装可能な次のAPIが用意されています。
電子商取引アプリケーションAPIの実装。これらのAPIは、主に支払処理に使用されます。
Oracle Paymentsには、電子商取引アプリケーションをOracle Paymentsと統合するための各種APIが用意されています。
事前統合されているOracleアプリケーション以外の電子商取引アプリケーションを使用している場合は、アプリケーションをOracle Paymentsにリンクするために、電子商取引アプリケーションのAPIを実装する必要があります。
電子商取引アプリケーションは、Oracle Paymentsの機能をそのアプリケーション内に埋め込むことができます。この結果、Oracle Paymentsにはスタンドアロン・アプリケーションとしてアクセスする必要がなくなるため、パフォーマンスが向上し、設定が簡素化されます。
この項では、Oracle Paymentsの機能を使用するために電子商取引アプリケーションに提供されている様々なAPIについて説明します。APIは次のカテゴリに分類されています。
Oracle Paymentsでは、次のプログラミング言語でAPIが提供されます。
次の図は、APIとOracle Paymentsの統合を示しています。
APIとOracle Paymentsの統合
支払手段APIは、支払人の銀行、クレジット・カード、暗証番号不要のデビット・カードまたは購買カードを登録する機能を提供します。
このAPIは、ユーザーの銀行、クレジット・カード、暗証番号不要のデビット・カードまたは購買カードのアカウント情報をOracle Paymentsに登録するために提供されています。この登録が成功すると、Oracle PaymentsによりPmtInstIdが生成されます。この識別子は、支払取引、またはこのアカウントの削除、変更または照会に使用されます。手段番号（クレジット・カード番号、暗証番号不要のデビット・カード、購買カード番号または銀行口座番号）と支払人識別子が全体で一意であることが必要です。
このAPIは、Oracle Paymentsに登録済の支払手段アカウント情報を変更するために提供されています。
このAPIは、登録済の支払手段アカウント情報を削除するために提供されています。
照会APIは2つあります。1つは、単一の特定の手段に関する手段情報を問い合せます。もう1つは、特定の支払人に関するすべての登録済支払手段を問い合せます。問合せ結果には、クレジット・カード、暗証番号不要のデビット・カード、購買カードまたは銀行口座の混合情報が含まれます。
これらのAPIは、様々な支払操作をサポートする取引APIです。電子商取引アプリケーションは、これらのAPIを使用して、様々な取引タイプを処理します。たとえば、クレジット・カード、暗証番号不要のデビット・カードおよび購買カードの承認、ある銀行口座から別の銀行口座への送金、取得、取消、差戻しなどがあります。このようなAPIのリストを次に示します。
このAPIは、クレジット・カード、暗証番号不要のデビット・カードおよび購買カードの支払に対する承認、および取得を伴う承認をサポートします。また、インバウンド口座振替および電子送金のオンライン検証もサポートします。
電子商取引アプリケーションは、支払要求を起動（多くの場合ユーザー処理によって起動）する準備が整ったときに、このAPIをコールします。操作が成功すると、Oracle Paymentsによって取引識別子が生成され、結果の一部として戻されます。この取引識別子は、支払で他の操作を開始するために、電子商取引アプリケーションが後で使用できます。
たとえば、支払を変更または取得するために、電子商取引アプリケーションは、要求した操作の実行に必要な他の情報とともにこの識別子を送信します。
支払がクレジット・カード、暗証番号不要のデビット・カードまたは購買カードの支払のいずれかで、要求がオンラインである場合、Oracle Paymentsでは支払要求（承認）と同時にリスク分析を実行できます。
承認と同時のリスク分析を可能にするには、その入力オブジェクト（詳細はJavaドキュメントを参照）のいずれかでリスク・フラグをTRUEに設定した支払要求を設定するか、該当する受取人に対する「リスク管理ステータス」画面で「使用可能」ラジオ・ボタンを選択します。いずれかの条件が満たされた場合、電子商取引アプリケーションは、支払応答オブジェクトの一部として支払要求APIに戻されるRiskrespオブジェクトをチェックします。また、支払要求APIを起動すると、PaymentRiskInfoオブジェクトを渡すことによって特定の算式を評価できます。
このAPIは、Oracle Paymentsで後続操作を処理できるようにする音声承認が実行された後にも使用されます。音声承認に使用するには、音声承認フラグをTRUEに設定し、承認コード変数を金融機関が発行する承認コードに設定した支払要求の入力オブジェクトを設定します。詳細は、Oracle PaymentsのJavaドキュメントを参照してください。
電子商取引アプリケーションでこのAPIを使用すると、支払予定を取り消すことができます。
このAPIは、支払のステータスまたは履歴を照会するためのインタフェースを電子商取引アプリケーションに提供します。支払が予定されていて、支払システムで照会操作がサポートされている場合、最新のステータスは支払システムから取得されます。それ以外の場合は、Oracle Paymentsにある支払の最新ステータスが送信されます。支払の履歴も取得できます。
支払要求の一部としてクレジット・カードまたは購買カードが使用され、承認のみが要求された場合、電子商取引アプリケーションは、後で支払を取得する必要があります。次のAPIを使用すると、電子商取引アプリケーションはこのような支払をすべて取得できます。
このAPIは、クレジット・カード、暗証番号不要のデビット・カードおよび購買カードの特定の操作に使用されます。支払人からの差戻しを処理できます。
ゲートウェイ・モデル支払システムは、取得操作をオンラインで処理します。取得がまだゲートウェイのオープン・バッチにある（つまり、バッチがクローズされていない）場合は、OraPmtVoidをコールする必要があります。バッチがクローズされている場合は、OraPmtReturnをコールする必要があります。差戻しを処理するには、バッチを再度クローズする必要があります。ゲートウェイはバッチを自動的にクローズ（例: 毎日1回）するように設定されている場合があるため、この処理で混乱が生じる可能性があります。
プロセッサ・モデル支払システムは、取得をオフラインで処理します。取得がまだ支払のオープン・バッチにある場合は、OraPmtVoidをコールします。バッチがクローズされている場合は、OraPmtReturnをコールします。差戻しを処理するには、差戻し操作後にバッチを再度クローズする必要があります。
このAPIは、支払要求（OraPmtReq API）時に送信された支払関連情報を取得します。この情報には、支払手段、受取人、有形資産ID（請求書または指示書）および支払人が含まれています。電子商取引アプリケーションに支払情報が保存されていない場合、このAPIは、支払要求の変更をサポートするための有効なAPIとなります。支払情報を取得し、変更のためにエンド・ユーザーに対して表示できます。
このAPIを使用すると、電子商取引アプリケーションは、以前に発行した操作を無効にできます。OraPmtVoid APIは、特定のクレジット・カードおよび購買カード操作を無効にするためにのみサポートされています。Oracle Paymentsでは、オンラインおよびオフラインのOraPmtVoid APIコールがサポートされています。
承認の電子的な無効化は、一部のプロセッサまたはゲートウェイではサポートされていません。この機能をサポートしているカード発行銀行はわずかで、大多数はサポートしていません。承認の取消は、電話によって、または承認を失効させる方法によってのみ実施できます。
このため、Payments内では、オンライン承認に対するOraPmtVoidのコールによって、現行の支払システム・サーブレットが「ステータス8 - 操作は未サポート」を戻す結果となります。オフライン承認については、承認がまだ支払のオープン・バッチ内にあり、支払システムに送信されていない場合は無効にできます。
このAPIは、クレジットおよび電子送金（EFT）操作を提供します。電子商取引アプリケーションは、このAPIを使用して、顧客にスタンドアロンのクレジットを提供できます。操作が成功すると、Oracle Paymentsによって取引識別子が生成されます。この取引識別子は、支払で他の操作を開始するために、後で使用されます。たとえば、クレジットを取り消すために、電子商取引アプリケーションは、取消の実行に必要な他の情報とともにこの識別子を送信します。
バッチのクローズAPIを使用すると、受取人または電子商取引アプリケーションは、以前に実行したクレジット・カードまたは購買カード取引、および必要な場合は暗証番号不要のデビット・カードのバッチをクローズできます。バッチに含まれる取引タイプは、取得、差戻しおよびクレジットです。この操作は、端末ベースの業者については必須です。
ホスト・ベースの業者は、バッチを明示的にクローズする必要がない場合があります。これは、バッチは通常、プロセッサによって事前に決定された間隔で自動的にクローズされるためです。電子商取引アプリケーションは、この情報を業者のアクワイアラから取得する必要があります。
このAPIは、既存のバッチおよびクローズ済のバッチのステータスを問い合せるためのインタフェースを電子商取引アプリケーションに提供します。
これらのAPIを使用すると、電子商取引アプリケーションは、クレジット・カード、暗証番号不要のデビット・カードおよび購買カードの取引とは別にリスク分析を実行できます。これらのAPIを組み合せて、受取人に対して構成されるあらゆる算式を評価できます。
リスク算式には、様々な重み付けを関連付けたリスク要因をいくつでも含めることができます。リスクAPI 1は、コールされると、AVSコード・リスク要因を除いて、算式に構成されているすべての要因を評価します。リスク算式にAVSコード・リスク要因が含まれている場合、リスクAPI 1は、応答オブジェクトで、算式にAVSコード・リスク要因が含まれていることを示します。この結果、電子商取引アプリケーションは、リスク算式を完全にまたは部分的に確認でき、承認を実行するかどうかを決定できます。
最初のリスクAPI 1の応答で支払にリスクがないことが示されると、電子商取引アプリケーションは承認を実行し、リスクAPI 2をコールして残りの評価を完了します。
電子商取引アプリケーションは、同じ受取人ID、算式名、および承認応答で戻されたAVSコードとリスクAPI 1の応答の一部として戻されたリスク・スコアを渡すことによって、リスクAPI 2をコールすることができます。リスクAPI 2の応答オブジェクトには、最終的に評価されたリスク・スコアが含まれています。
このAPIは、入力オブジェクトPmtRiskInfoの一部として渡された受取人IDに関連付けられているリスク算式を評価します。このAPIは、入力オブジェクトに応じて、特定の算式または暗黙算式を評価できます。評価後、このAPIは、フラグAVSCodeFlagを設定して、AVSコード・リスク要因が算式に含まれているかどうかを示す応答オブジェクトを作成します。このフラグがTRUEに設定されている場合、電子商取引アプリケーションは、算式のリスク評価を完了するためにリスクAPI 2をコールする必要があります。
このAPIは、RiskAPI 1応答オブジェクト内のAVSCodeFlagで、算式にAVSコード要因が含まれていることが示された場合にコールする必要があります。このAPIは、コールされると、AVSコード要因のみを評価します。このAPIの入力オブジェクトには、リスクAPI 1で渡された同じ受取人IDと算式名、および支払要求に対して支払システムから戻されたAVSコードが含まれています。このAPIが戻す応答オブジェクトには、算式の最終リスク・スコアが含まれています。
クレジット・カード検証APIは、クレジット・カード番号のクレジット・カード・タイプの特定、および基本認証の実行のためのメソッドを提供します。ほとんどのクレジット・カード・タイプには、その企業名の有効なすべてのクレジット・カード・アカウントに対する桁数とプリフィクスが指定されているため、たいていのクレジット・カード番号のクレジット・カード・タイプは判別が可能です。また、ほとんどのクレジット・カード・タイプの数字は、（特殊なアルゴリズムを使用して）10で割り切れる必要があるため、クレジット・カード番号が有効であるかどうかの判別が可能です。これらのAPIでは、請求先所在地検証など、バックエンド支払システムで使用可能な一部の高度なクレジット・カード検証技術は実行されません。これらのAPIを使用すると、入力ミスやクレジット・カード桁数の切捨てなど、多数の一般的なエラーを検出できます。電子商取引アプリケーションで一般的なエラーを検出できるため、パフォーマンスが向上します。これは、これらのAPIのコール費用が、要求をバックエンド支払システムに送信するより大幅に少なくてすむためです。
クレジット・カード検証APIは、IBY_CC_VALIDATEパッケージの一部として作成され、このパッケージはAPPSスキーマにインストールされています。
クレジット・カード検証APIは、3つの主なメソッドで構成されています。
メソッドStripCCは、顧客が入力したままのクレジット・カード番号をフォーマットするために使用されます。ハイフンや空白などの一般的な充填文字を削除して、数字のみで構成されるクレジット・カード番号を生成します。StripCCは、クレジット・カード番号が他のメソッドに渡される前にコールする必要があります。
メソッドGetCCTypeは、クレジット・カード番号のクレジット・カード・タイプを戻します。この場合の各クレジット・カード・タイプは、無効および不明なタイプに対する値も含めて、パッケージ内の定数です。
メソッドValidateCCは、クレジット・カード番号と日付の両方を使用します。クレジット・カードがまだ使用可能かどうかを示すブール値を戻します。
注意: INパラメータp_api_versionとp_init_msg_listおよびOUTパラメータx_msg_countとx_msg_dataは無視されます。予期しないエラーが発生した場合は、x_return_statusにFND_API.G_RET_STS_UNEXP_ERRORが設定されます。これは、クレジット・カード番号に無効な文字が含まれている場合に発生します。
DECLARE-- each character specifies a possible filler characters in the credit -- card number; i.e. a character that can safely be stripped awayp_fill_chars VARCHAR(3) := '* -#';p_cc_number VARCHAR(20) := '4111*1111 1111-1111#';p_api_version NUMBER := 1.0;p_init_msg_list VARCHAR2(2000) := ' ';x_return_status VARCHAR2(2000);x_msg_count NUMBER;x_msg_data VARCHAR2(2000);-- will hold the credit card number stripped of all characters except -- digits; credit card numbers must be of this form for the GetCCType-- and ValidateCC methodsv_clean_cc VARCHAR(20);-- variable to be set by GetCCType methodv_cc_type IBY_CC_VALIDATE.CCType;-- variable set by ValidateCC method; indicates if the credit card is -- still usablev_cc_valid BOOLEAN;-- credit card expr date; rolled to the end of the month-- by the ValidateCC methodv_expr_date DATE := SYSDATE();BEGIN-- the credit card number must first be stripped of all non-digits!!IBY_CC_VALIDATE.StripCC( p_api_version, p_init_msg_list, p_cc_number, p_fill_chars, x_return_status, x_msg_count, x_msg_data, v_clean_cc );-- check that illegal characters were not foundIF x_return_status != FND_API.G_RET_STS_UNEXP_ERROR THEN IBY_CC_VALIDATE.GetCCType( p_api_version, p_init_msg_list, v_clean_cc, x_return_status, x_msg_count, x_msg_data, v_cc_type); IF x_return_status != FND_API.G_RET_STS_UNEXP_ERROR THEN IF v_cc_type=IBY_CC_VALIDATE.c_InvalidCC THENDBMS_OUTPUT.PUT_LINE('Credit card number not a valid one.'); ELSEDBMS_OUTPUT.PUT_LINE('Credit card number OK.'); END IF; IBY_CC_VALIDATE.ValidateCC( p_api_version, p_init_msg_list, v_clean_cc, v_expr_date, x_return_status, x_msg_count, x_msg_data, v_cc_valid); IF v_cc_valid THENDBMS_OUTPUT.PUT_LINE('Credit card is valid.'); ELSEDBMS_OUTPUT.PUT_LINE('Credit card number invalid or has expired.'); END IF;END IF;END;注意: StripCCメソッドのオーバーロード・バージョンが存在します。このバージョンは、p_fill_charsを除いて、前述のバージョンとすべて同じ引数を使用します。パッケージ定数c_FillerCharsから充填文字を取得するため、クレジット・カード番号の間に空白やハイフンを使用できます。
Oracle Paymentsには、オフライン支払処理を実行する場合に電子商取引アプリケーションで実装する必要があるPL/SQL APIが定義されています。このAPIを使用すると、電子商取引アプリケーションでステータス更新を受信できます。このAPIはパッケージで定義される必要があります。パッケージの命名規則およびAPIの署名は次に示すように定義されます。電子商取引アプリケーションは、オフライン支払がある場合、定義されている構文に従ってパッケージを実装し、APPSスキーマ内にパッケージを作成する必要があります。
パッケージ名の書式は<application_short_name>_ecapp_pkgであることが必要です。application_short_nameは、電子商取引アプリケーション登録で付与された3文字の短縮名です。パッケージには、次の署名が含まれるupdate_statusプロシージャが定義されている必要があります。
PROCEDURE UPDATE_STATUS( totalRows IN NUMBER,txn_id_Tab IN APPS.JTF_VARCHAR2_TABLE_100,req_type_Tab IN APPS.JTF_VARCHAR2_TABLE_100,Status_Tab IN APPS.JTF_NUMBER_TABLE,updatedt_Tab IN APPS.JTF_DATE_TABLE,refcode_Tab IN APPS.JTF_VARCHAR2_TABLE_100,o_status OUT VARCHAR2,o_errcode OUT VARCHAR2,o_errmsg OUT VARCHAR2,o_statusindiv_Tab IN OUT APPS.JTF_VARCHAR2_TABLE_100);次のリストで、これらの署名のフィールド名について説明します。
totalRows: 更新用に渡される合計行数。
txn_id_Tab: 更新を送信する先の取引識別子の表。
req_type_Tab: 取引識別子に対応する要求タイプの表。各取引について、req_typeが関連付けられており、電子商取引アプリケーションは、txn_idとreq_typeに基づいて適切な取引を更新する必要があります。req-typeを設定する理由は、取引を一意に識別するためです。同じ取引識別子に対して、複数の取引（例: 承認と取得）がある場合があります。電子商取引アプリケーションは、trxnidとreq_typeの値に基づいて取引を一意に識別できます。
次の表に、様々な要求タイプとその説明を示します。
| req_type | 説明 |
|---|---|
| ORAPMTCAPTURE | 取得取引 |
| ORAPMTCREDIT | クレジット取引 |
| ORAPMTREQ | 承認取引 |
| ORAPMTRETURN | 差戻し取引 |
| ORAPMTVOID | 無効取引 |
Status_Tab: 各取引に対応するステータスの表。
次の表に、いくつかの値とそのステータスを示します。
| 値 | ステータス |
|---|---|
| 0 | 支払済 |
| 5 | 支払失敗 |
| 13 | 予定 |
| 15 | 失敗 |
| 17 | 未払 |
| 18 | 発行済 |
注意: 値とそのステータスの完全なリストは、表D-15を参照してください。
updatedt_Tab: 各取引の最終更新日の表。
refcode_Tab: 各取引の参照コードの表。
o_status: プロシージャの全体的なステータス。プロシージャの実行でエラーが発生した場合、電子商取引アプリケーションは、このフィールドに適切な値を設定する必要があります。
o_errcode: 処理時に発生した可能性があるエラーのエラー・コード。
o_errmsg: エラーのエラー・メッセージ。
o_statusindiv_Tab: 更新されたステータス値の表。特定の取引に対するステータス値を電子商取引アプリケーションが更新した場合は、その取引に対する値をTRUEに設定し、更新していない場合はFALSEに設定する必要があります。
注意: このプロシージャでは、取引ごとに、表パラメータに1つのエントリが作成されます。この電子商取引アプリケーションの取引が10個あり、そのステータスが変更された場合、各表パラメータのエントリは10個になります。
スケジューラは実行のたびに、予定されているすべてのオフライン支払取引を選択します。すべてのオフライン支払取引が成功または失敗のいずれかで処理された後、スケジューラは、各取引のステータス変更（ある場合）の最新情報を適切な電子商取引アプリケーションに通知する必要があります。電子商取引アプリケーションに最新情報を通知するために、スケジューラは、その電子商取引アプリケーションで実装されているPL/SQL APIをコールします。
各行の更新の場合、そのステータスは要求タイプと取引識別子に基づいています。更新が成功した場合は、ステータスの値が適切に設定されます。
for i in 1..totalRows;update the tables with status, updatedate, and refinfo informationupdate tables using status_Tab[i], updatedt_Tab[i], refCode_Tab[i] for the transaction with id txn_id_Tab[i] and req_type_tab[i]if update is successful o_statusindiv_Tab[i] := 'TRUE'else o_statusindiv_Tab[i] := 'FALSE'end for;return管理機能およびインバウンド支払処理機能はすべて、Java PaymentServiceインタフェースを介して提供されます。次の情報は、Java APIのアクセス方法と使用方法を説明しています。詳細は、Oracle PaymentsのJavaDocを参照してください。
注意: 操作を実行するには、ゲスト・ユーザー・プロパティがデータベースに設定されている必要があります。詳細は、CRM Foundationで提供されている設定マニュアルを参照してください。
OraPmtクラスには、ユーザーのために支払サービス・ハンドル（PaymentService）を取得する便利な方法が用意されています。アプリケーションは、このハンドルを使用して様々なAPIをコールできます。
支払サービス・ハンドルを取得するには、次のメソッドを使用します。
static public PaymentService init() throws PSException
このAPIは、ユーザーに支払サービス・ハンドルを提供し、必要なすべてのセッション初期化ステップを処理します。
セッションとともに支払サービス・ハンドルを解放するには、次のメソッドを使用します。
static public void end() throws PSException
次のコードは、これらのAPIの使用方法の例を示しています。
public static void main(String[] args) {
try {
PaymentService paymentService = OraPmt.init();
// now you can call all kinds of APIs
//PSResult result = paymentService.OraPmtReq(...);
} catch (PSException pe) {
// exception handling
System.out.println("Error code is: " + pe.getCode());
System.out.println("Error message is: " + pe.getMessage());
}
finally {
try {
OraPmt.end();
} catch (PSException pe) {
// exception handling
System.out.println("Error code is: " + pe.getCode());
System.out.println("Error message is: " +
pe.getMessage());
}
}
}
PSResultは、すべてのPaymentService APIの戻りオブジェクトです。操作のステータスを取得するには、次のAPIを使用します。
public String getStatus();
This API returns one of the following constants:
PSResult.IBY_SUCCESS// action succeeded
PSResult.IBY_WARNING// action succeeded with warning
PSResult.IBY_INFO// not yet in use
PSResult.IBY_FAILURE// action failed
SUCCESSまたはWARNINGが起動された場合、結果オブジェクトは常に、次のAPIを使用して取得できます。
public Object getResult();
FAILUREが起動された場合に、この失敗がバックエンド支払システムで発生した場合は、支払操作APIに対する結果オブジェクトが戻されることがあります。
戻された実際のオブジェクトは各APIによって異なります。整数の場合や支払応答オブジェクトの1つの場合などがあります。これは明確にキャストする必要があります。キャスト方法のリストは、PaymentServiceインタフェースに関するOracle PaymentsのJavaドキュメントを参照してください。
WARNINGまたはFAILUREが起動された場合は、警告またはエラー・メッセージが戻されます。エラー・コードおよびエラー・メッセージを取得するには、次の2つのAPIを使用します。
public String getCode();// get the error code 'IBY_XXXXXX'
public String getMessage(); // get the error message text
次のサンプル・コードは、PSResultオブジェクトの動作の例を示しています。
public Object checkResult(PSResult pr) {
String status = pr.getStatus();
if (status.equals(PSResult.IBY_FAILURE)) {
// in case of failure, only error message is expected
System.out.println("error code is : " + pr.getCode());
System.out.println("error message is : " + pr.getMessage());
Object res=pr.getResult();
if (res!=null) System.out.printIn ("failure occured with backend Payment system");
return res;
}
if (status.equals(PSResult.IBY_SUCCESS)) {
// in case of success, only result object is expected
Object res = pr.getResult();
return res; // you need cast this to specific object
// based on the APIs you called
}
if (status.equals(PSResult.IBY_WARNING)) {
// in case of warning, both result object and message are
// expected
// warning is returned only for Payment APIs in case of
// offline scheduling
System.out.println("warning code is : " + pr.getCode());
System.out.println("warning message is : " + pr.getMessage());
Object res = pr.getResult();
return res; // you need cast it here too
}
// currently IBY_INFO is not yet returned by any PaymentService API
System.out.println("Illegal status VALUE in PSResult! " +
pr.getStatus());
return null;
}
OraPmtクラスを介して支払サービス・ハンドルが取得された後は、支払サービス・インタフェースでは次に示すいずれかのAPIをコールできます。詳細は、JavaDocを参照してください。
次に、支払手段APIおよび支払処理APIのサンプル・コードをいくつか示します。これらのコードでは、checkResultのコールが使用されます。
public void instrAPISample(PaymentService paymentService,
int ecappId) {
PSResult pr;
Object obj;
CreditCard cc;
Address addr;
int instrid_cc;
String payerid = "payer1";
addr = new Address("Line1", "Line2", "Line3", "Redwood Shores",
"San Mateo", "CA", "US", "94065");
// credit card
cc = new CreditCard();
cc.setName("My Credit Card");
cc.setFIName("Paymentech");
cc.setInstrBuf("This is my credit card description.");
cc.setInstrNum("4111111111111111"); // the credit card number
cc.setCardType(Constants.CCTYPE_VISA); // the credit card type, should
// match the credit card number, if set
cc.setExpDate(new java.sql.Date(101, 0, 10)); // Jan 10, 2001
cc.setHolderName("Mary Smith");
cc.setHolderAddress(addr);
// add the credit card
pr = paymentService.oraInstrAdd(ecappId, payerid, cc);
obj = checkResult(pr);
if (obj == null) return; // registration failure
instrid_cc = ((Integer) obj).intValue();
System.out.println("Credit card registered successfully " +
"with instrument id " + instrid_cc);
}
// perform an ONLINE credit card authorization with payment service
public void paymentAPISample(PaymentService paymentService, int ecAppId) {
Bill t;
CoreCreditCardReq reqTrxn;
CreditCard cc;
PSResult pr;
CoreCreditCardAuthResp resp;
// set up the tangible object
t = new Bill();
t.setId("orderId1");
t.setAmount(new Double(21.00));
t.setCurrency("USD");
t.setRefInfo("refInfo");
t.setMemo("memo");
t.setUserAccount("userAcct");
// set up the transaction object
reqTrxn = new CoreCreditCardReq();
reqTrxn.setNLSLang("American_America.US7ASCII");
reqTrxn.setMode(Transaction.ONLINE);
reqTrxn.setSchedDate(new java.sql.Date(100, 5, 10)); //June 10, 2000
reqTrxn.setAuthType(Constants.AUTHTYPE_AUTHONLY);
// set up the payment instrument
cc = new CreditCard();
cc.setId(100); // assuming we have previously registered credit
// card with instrument id 100
pr = // assuming payee1 has already been configured with the payment
// service
paymentService.oraPmtReq(ecAppId, "payee1", "", cc, t,
reqTrxn);
resp = (CoreCreditCardAuthResp) checkResult(pr);
if (resp == null) return;
System.out.println("Request finished with transaction id: " +
resp.getTID());
}
public void instrAPISample(PaymentService paymentService,
int ecappId) {
PSResult pr;
Object obj;
PurchaseCard pc;
Address addr;
int instrid_pc;
String payerid = "payer1";
addr = new Address("Line1", "Line2", "Line3",
"Redwood Shores", "San Mateo", "CA",
"US", "94065");
// purchase card
pc = new PurchaseCard();
pc.setName("My Purchase Card");
pc.setFIName("Paymentech");
pc.setInstrBuf("This is my purchase card description.");
pc.setInstrNum("4111111111111111"); // the purchase card
// number
pc.setCardType("Constants.CCTYPE_VISA"); // the purchase
// card type, should match the purchase card number, if
// set
pc.setCardSubtype("P");
pc.setExpDate(new java.sql.Date(101, 0, 10));
// Jan 10, 2001
pc.setHolderName("Mary Smith");
pc.setHolderAddress(addr);
// add the purchase card
pr = paymentService.oraInstrAdd(ecappId, payerid, pc);
obj = checkResult(pr);
if (obj == null) return; // registration failure
instrid_pc = ((Integer) obj).intValue();
System.out.println("Purchase Card registered " +
"successfully with instrument id " +
instrid_pc);
}
// perform an ONLINE purchase card authorization with
// payment service
public void paymentAPISample(PaymentService paymentService,
int ecAppId) {
Bill t;
PurchaseCardReq reqTrxn;
PurchaseCard pc;
PSResult pr;
CoreCreditCardAuthResp resp; // since purchase card
// authorization responses are identical to credit card
// responses. See javadoc for details.
// set up the tangible object
t = new Bill();
t.setId("orderId1");
t.setAmount(new Double(21.00));
t.setCurrency("USD");
t.setRefInfo("refInfo");
t.setMemo("memo");
t.setUserAccount("userAcct");
// set up the transaction object
reqTrxn = new PurchaseCardReq();
reqTrxn.setNLSLang("American_America.US7ASCII");
reqTrxn.setMode(Transaction.ONLINE);
reqTrxn.setSchedDate(new java.sql.Date(100, 5, 10));
// June 10, 2000
reqTrxn.setAuthType(Constants.AUTHTYPE_AUTHONLY);
reqTrxn.setPONum("PONum");
reqTrxn.setTaxAmount("1.50");
reqTrxn.setShipToZip("94065");
reqTrxn.setShipFromZip("94404");
// set up the payment instrument
pc = new PurchaseCard();
pc.setId(100); // assuming we have previously registered
// purchase card with instrument id 100
pr = // assuming payee1 has already been configured with
// the payment service
paymentService.oraPmtReq(ecAppId, "payee1", "", pc,
t, reqTrxn);
resp = (CoreCreditCardAuthResp) checkResult(pr);
if (resp == null) return;
System.out.println("Request finished with " +
"transaction id: " + resp.getTID());
}
Oracle Paymentsは、支払操作の処理にPL/SQLインタフェースを必要とするまたは優先する電子商取引アプリケーションに対して、PL/SQL APIを提供します。PL/SQL APIのコール時に、追加のHTTPコールが実行されます。電子商取引アプリケーションがこれらのPL/SQL APIを起動すると、そのAPIがHTTPを介して電子商取引サーブレットをコールします。
Oracle PaymentsのPL/SQL APIでは、すべての支払関連処理APIおよび2つのリスクAPIが提供されます。これらのAPIの機能は、Java APIと同じです。
PL/SQL APIは、IBY_PAYMENT_ADAPTER_PUBパッケージの一部として作成され、これらのパッケージはAPPSスキーマにインストールされています。
要件は次のとおりです。
PL/SQLパッケージIBY_PAYMENT_ADAPTER_PUBがAPPSスキーマにインストールされている必要があります。
管理者は、Oracle Payments管理ユーザー・インタフェースを使用して、APIの起動前に、Oracle PaymentsのURLプロパティにOracle Payments電子商取引サーブレットのURLを設定する必要があります。
次のPL/SQLコードは、Oracle PaymentsのPL/SQL APIの起動方法の理解に役立ちます。このコード例では、クレジット・カードを使用して支払要求APIが起動されます。また、リスク評価のためにリスク関連情報が渡されます。
DECLARE
p_api_version NUMBER := 1.0;
--To initialize message list.
p_init_msg_list VARCHAR2(2000) := FND_API.G_TRUE;
p_commit VARCHAR2(2000) := FND_API.G_FALSE;
p_validation_level NUMBER := FND_API.G_VALID_LEVEL_FULL;
p_ecapp_id NUMBER := 0;
p_payee_rec IBY_PAYMENT_ADAPTER_PUB.Payee_rec_type;
p_payer_rec IBY_PAYMENT_ADAPTER_PUB.Payer_rec_type;
p_pmtinstr_rec IBY_PAYMENT_ADAPTER_PUB.PmtInstr_rec_type;
p_tangible_rec IBY_PAYMENT_ADAPTER_PUB.Tangible_rec_type;
p_pmtreqtrxn_rec IBY_PAYMENT_ADAPTER_PUB.PmtReqTrxn_rec_type;
p_riskinfo_rec IBY_PAYMENT_ADAPTER_PUB.RiskInfo_rec_type;
x_return_status VARCHAR2(2000);
-- output/return status
x_msg_count NUMBER;
-- output message count
x_msg_data VARCHAR2(2000);
-- reference string for getting output message text
x_reqresp_rec IBY_PAYMENT_ADAPTER_PUB.ReqResp_rec_type;
-- request specific output response object
l_msg_count NUMBER;
l_msg_data VARCHAR2(2000);
BEGIN
p_ecapp_id := 66; -- iPayment generated ECAppID
p_payee_rec.Payee_ID := 'ipay-payee1'; -- payee's ID
p_payer_rec.Payer_ID := 'ipay-cust1'; -- payer's ID
p_payer_rec.Payer_Name := 'Cust1'; -- Payer's (Customer's name)
p_pmtreqtrxn_rec.PmtMode := 'ONLINE';
-- Payment mode (Can be ONLINE/OFFLINE)
p_tangible_rec.Tangible_ID := 'tangible_id1'; -- Tangible ID / order ID
p_tangible_rec.Tangible_Amount := 25.50; -- Amount for the transaction
p_tangible_rec.Currency_code := 'USD'; -- Currency for the transaction
p_tangible_rec.RefInfo := 'test_refinfo3';
p_pmtreqtrxn_rec.Auth_Type := upper('authonly'); -- request type
p_pmtinstr_rec.CreditCardInstr.CC_Type := 'Visa';
-- payment instrument type
p_pmtinstr_rec.CreditCardInstr.CC_Num := '4111111111111111';
-- payment instrument number
p_pmtinstr_rec.CreditCardInstr.CC_ExpDate := to_char(sysdate+300);
-- payment instr. Expiration date
--5. RISK INPUTS
p_riskinfo_rec.Formula_Name := 'test3'; -- Risk formula name
p_riskinfo_rec.ShipToBillTo_Flag := 'TRUE';
-- Flag showing if ship to address same as Bill to address
p_riskinfo_rec.Time_Of_Purchase := '08:45';
-- Time of purchase
IBY_PAYMENT_ADAPTER_PUB.OraPmtReq
( p_api_version,
p_init_msg_list,
p_commit,
p_validation_level,
p_ecapp_id ,
p_payee_rec,
p_payer_rec,
p_pmtinstr_rec,
p_tangible_rec,
p_pmtreqtrxn_rec,
p_riskinfo_rec ,
x_return_status,
x_msg_count ,
x_msg_data ,
x_reqresp_rec);
END;
Payment Request Related Response. Printing Only If Status Is Success
If(Char(X_Reqresp_Rec.Response.Status = ‘S') Then
-- Offline Mode Related Response
If P_Pmtreqtrxn_Rec.Pmtmode = 'OFFLINE' Then
Dbms_Output.Put_Line('Transaction ID = ' || To_Char(X_Reqresp_Rec.Trxn_ID));
Dbms_Output.Put_Line (‘ X_Reqresp_Rec.Offlineresp.Earliestsettlement_Date = ' ||
To_Char(X_Reqresp_Rec.Offlineresp.Earliestsettlement_Date));
Dbms_Output.Put_Line('X_Reqresp_Rec.Offlineresp.Scheduled_Date = ' ||
To_Char(X_Reqresp_Rec.Offlineresp.Scheduled_Date));
Else
Dbms_Output.Put_Line('Transaction ID = ' || To_Char(X_Reqresp_Rec.Trxn_ID));
Dbms_Output.Put_Line('X_Reqresp_Rec.Authcode = ' || X_Reqresp_Rec.Authcode);
Dbms_Output.Put_Line('X_Reqresp_Rec.Avscode = ' || X_Reqresp_Rec.Avscode);
Dbms_Output.Put_Line('-------------------------------------------');
-- Risk Related Response
If(X_Reqresp_Rec.Riskrespincluded = ‘YES') Then
Dbms_Output.Put_Line('-------------------------------------------');
Dbms_Output.Put_Line(' X_Reqresp_Rec.Riskresponse.Risk_Score= '|| X_Reqresp_Rec.Riskresponse.Risk_Score );
Dbms_Output.Put_Line('X_Reqresp_Rec.Riskresponse.Risk_Threshold_Val= '||
X_Reqresp_Rec.Riskresponse.Risk_Threshold_Val);
Endif;
Endif;
End If;
Oracle Paymentsは、クレジット・カードの詳細をURLで送信するように設計されています。このアーキテクチャでは、クレジット・カード情報がログ・ファイルに表示されないように、Apacheのロギング・レベルをデフォルトより低くする必要があります。
httpds.confファイルで、次の記述を変更します。
LogFormat "%h %l %u %t ¥"%r¥" %>s %b" common
変更後:
LogFormat "%h %l %u %t ¥"%U¥" %>s %b" common
