Orbipay uses the idempotent_request_key to identify duplicate API calls or requests.
The same idempotent_request_key value should be used if an API is being retried or if an API request is being resent. It is advised that a client retries an API request when the original request times out. When an API request is retried, the idempotent_request_key and the rest of the API request parameters, including the header parameters, except the timestamp, should exactly match those in the original request for the request to be accepted by Orbipay. An API request can be retried any number of times. Orbipay does not reprocess duplicate API requests and the idempotent_request_key helps ensure that an API request is processed exactly once. In addition to this, the idempotent_request_key can also be used as an identifier by client to trace an API request. https://developers.orbipay.com/paymentsapi/reference/#tag/Duplicate-Requests-and-Retrials
You can use any uniquely generated string like a database sequence, or a guid generator to generate idempotent_request_key. https://developers.orbipay.com/paymentsapi/reference/#tag/Request-Headers
It is recommended that the idempotent_request_key is not reused across APIs.
EBPP API returns a list of errors in the response body in JSON in case of failed requests. Each error has a code, message, and specifics on which field the error pertains to (if applicable).
Use any value for channel. However, the channel must be set up and configured appropriately in Orbipay. Contact support@billerpayments.com to set up a channel. https://developers.orbipay.com/paymentsapi/reference/#tag/Request-Headers
We support only add_to_principle through EBPP API, contact support for more information.
No, SDK will generate for you.
You must map the error codes which are relevant in your API, so that you will know the actual situation/scenario in which the error occurs. Contact support team to know the error scenarios.
If an API is being requested from an application that is being used directly by a customer, like the customer portal and IVR, the requestor_type should be set to “customer”. If an API is being requested from an application that is being used by third party agents/brokers servicing a customer on behalf of a biller/client, then the requestor_type should be set to “external_user”. It should be noted that these users would not have logins for the EBPP Payment Center (agent portal). If an API is being requested from an application that is being used by an agent or a customer service representative belonging to the biller/client organization, then the requestor_type should be set to “client_agent”. It should be noted that there should be a user in the EBPP Payment Center (agent portal) corresponding to this user. All API do not support all requestor types, check the respective API for the requestor types supported. The requestor_type is “system” when an API is invoked by a client system or process, independently, and not exclusively to fulfill a customer or agent request or action. https://developers.orbipay.com/paymentsapi/reference/#tag/Request-Headers
The identifier for the requestor of the API, in EBPP. The value to be passed in the requestor field depends on the requestor_type: If the requestor_type is “customer”, the requestor should be the EBPP generated customer id. In the case of self registration, where there is no EBPP generated customer id yet, the requestor should be set to ”guest”. If the requestor_type is “external_user”, the requestor can be any unique identifier that the client may have for the external agent. If the requestor_type is “client_agent”, the requestor should be the UMS id for the client agent user to the Orbipay EBPP Payment Center (agent portal). If the requestor_type is “system”, the requestor is optional and the value can be any unique identifier that the client may have for the system. https://developers.orbipay.com/paymentsapi/reference/#tag/Request-Headers
client_key is the unique identifier assigned by Orbipay to identify the client. Contact support@billerpayments.com for the value to be used. https://developers.orbipay.com/paymentsapi/reference/#tag/Request-Headers
api_key is the unique key, assigned by Orbipay to the client, which, along with the api secret, is used for authenticating API requests. This can be reset in case you doubt if it has been compromised. Contact support@billerpayments.com for the value to be used. https://developers.orbipay.com/paymentsapi/reference/#tag/Request-Headers
You’ll find SDKs for languages that we support at https://developers.orbipay.com/paymentsapi/versions/. The SDK is accompanied by the README (README.md) and CHANGELOG (CHANGELOG.md) too. Contact support@billerpayments.com if you do not find the SDK in the language of your choice.
SDKs for the Payments API and the Hosted Forms are available in various languages. Though it’s not mandatory to use an SDK, it provides many benefits. Some of the major benefits an SDK provides are:
- Obviates the need to implement the API authentication. The API authentication involves a bit of complicated logic that can sometimes overwhelm developers. The SDKs that we provide reduce that effort for you.
- Performs basic validation and checks that can avoid unnecessary and improper API calls.
The README lists the dependencies for using the SDK.
No problem. You can create a raw API request yourselves. However, you have to construct the API request header, Authorization following the API Reference documentation. You’ll also need to set the timestamp, conf_10t-type and consumes request headers. Contact support@billerpayments.com for assistance.https://developers.orbipay.com/paymentsapi/reference/#tag/Authentication
Yes.
Refer API Play ground (Jupyter code samples) which will have sample codes for enabling the SDK logs.
We mask all the sensitive fields while logging.
We mask all the sensitive fields while logging.
Currently we don’t have code sample for direct integration.
It gives you an exception/error object in error case, please refer API playground to know how to extract the error object.
It gives an exception object in any error scenario. Please refer API play ground to know how to extract the error object.
Please refer to API Playground (Jupyter Notes samples) which have sample codes for all APIs in all supported languages.
Contact support@billerpayments.com for assistance.
No, We don’t provide support without Authorization.
The absolute path component of the URI—everything starting with the “/” that follows the domain name and up to the end of the string or to the question mark character (“?”) if the given URL has query string parameters. https://developers.orbipay.com/paymentsapi/reference/#section/OPAY1-HMAC-SHAf_256
Please refer to API Play ground (Jupyter Notes samples) Authorization header section.
There is no option to disable Authorization check.
The response header, request_uuid or idempotent_request_key can help in tracing/debugging purpose.
Imagine a scenario where a customer needs to be created first, then a funding account needs to be added to the customer before a payment is made. This involves three API calls in a sequence. Each of the API calls would have separate request_id values. However, the three API calls are part of a logical unit of processing. It is advisable to use a common trace_id across these API calls. Please note that the trace_id can be used only for tracing and debugging across the API calls. It does not have any functional significance. It also does not imply or ensure that these API calls are processed as a single unit (transaction), where either all the API calls are successful or in the event one of them fails the previous ones are rolled back. The simplest value that you can use for the trace_id is a database sequence that would avoid inadvertent re-use or repetition.
No need to share any certificates as the API has public access.
No need to White list, as the API has public access.
As of now we don\'t have a rate limit on API calls, but we reject concurrent API requests.
Yes.
It depends on the timeout variables that you set, by default 60 seconds is set as read timeout in SDKs.
You can see an indication in SDK exception object, which specifies whether the request got timed out or not, Please refer to API Play ground (Jupyter code samples).
No.
Yes. you have to configure the same.
By comparing Authorization hash at server side, you can identify if the API request is tampered between the client and server.
EBPP handles nacha returns, card payment declines and chargebacks and reports clients on the same.
We have a set of Account Validation APIs. https://developers.orbipay.com/ibavapi/reference/
The status attribute in the Payment response object indicates the payment status. You can opt for notifications to be notified on the same.
Both are same, the EBPP generated customer id. While representing it in the URL, we use customer_id to specify that it is the id of customer.
The EBPP generated customer id.
Based on the logs tables we identify the ip address, and can differentiate the requests.
To identify and trace the requests, store the idempotency_key,request_uuid,http_status_code and EBPP generated IDs of all the resources.
Use custom_fields attribute to send metadata. You should configure it in EBPP beforehand sending the metadata.
Custom fields are useful for storing additional structured information on an object.
Currently, we support 64 normal fields and 12 secure fields.
You can identify based on the the uniqueness criteria opted by client.
It is a field by which client can identify customers, it could be customer_reference or account_number.
No.
You can have multiple accounts for a single customers if uniqueness criteria is customer_reference.
Based on the Fraudulent identification or Nacha return rules will place a customer in appropriate status, Contact support team for more information.
Depends on your business case. Contact support for more information.
Based on the severity of the Nacha return code or Fraudulent identification, Contact support team for more information.
bank, credit_card and debit_card. https://developers.orbipay.com/paymentsapi/reference/#tag/Funding-Account
We have a test gateway setup. Contact support team for the details.
You can use Simple Payment API.https://developers.orbipay.com/paymentsapi/reference/#operation/simplePayment
We don’t support funding account sharing through the EBPP API.
Funds will be credited to original account that was used when making the payment even though you haven’t saved the card.
A recorded payment is not an actual payment that is useful to record payments that are made and fulfilled outside EBPP.
The Status attribute in Payment response indicates the status of the payment.
Scheduled.
Scheduled.
Scheduled.
Processing.
We don’t process cash/cheque payments in EBPP, we just record them in the system.
funding_account section is optional for making cash/cheque payments, you can pass account_number, issuer_name for reference purpose.
We don’t support refund on cash/cheque payments.
One time and payment setups (autopay_enrollment, variable_recurring_enrollment, payment_plan) are supported in EBPP API.
The type of amount, as per the bill/statement, that is being paid. The payment amount is derived from the amount type selected for the payment.
The date on which the biller wants the payment to be settled. You cannot use the payment_request_date attribute in the API unless you enable it in EBPP.
Payment setup acts as a template and the actual debit happens when an instance of a Payment Setup is created on the due to date configured from the back end system recursively.
No.
You can add overseas card to make international payments, you have to be configured in EBPP system to make use of it. As of now we don’t support international payments with bank accounts.
To authorize the card while creating payment setup, since CVV is not available at the time of debit (creating an instance of a Payment Setup).
You can use id of the payment or confirmation_number also can be used to identify a payment.
It should not be a customer facing channel, please contact support team for more details.
It should not be customer as we don’t allow customer to initiate refund on a payment, please contact support team for more details.
Depends on the payment processing network/gateway that you configure.
Depends on the payment processing network/NACHA rules.
You can refund a payment multiple times with partial amounts not exceeding the original payment amount.
You can pass fee_refund attribute in create refund request.
Original payment must be in either processing/processed status and it should not exceed the maximum number of days from scheduling as configured for refunds.
Based on the last modified time on the object,resource will order them in the descending order.
Pagination acts as server side on the results returned based on your search criteria. You don’t have to store all the results in memory and use it for pagination in your application.
It is a unique identifier for the search criteria that you passed when initiating a search vide a retrieve API. The query_id is required for the subsequent pagination calls.
You can make subsequent pagination calls by passing query_id, from_index or to_index and page_size attributes to iterate on the results.
Currently, it is 99 per page.
We have set 5000 as max results at server side, if your search exceeds 5000 records, API will respond with error, error_refine_search.
