Support
During development, you may always reach out to the UGA Finance development team for support at: salesforcedev@ugafinance.com When requesting support, we recommend you send the following when debugging specific endpoints: Make sure to remove any sensitive information when sending data!- The endpoint you’re connecting to.
- The request headers
-
The request body
- Any sensitive data should be removed.
- The response body
API - General Usage
API Base URLs
Your credentials will be different for each environment. Don’t expect
your sandbox credentials to also work in the production environment!
Requirements
In order to use the uPortal360 API, you must have the following:- OAuth 2.0 Protocol
- TLS 1.2
- User-Agent Header
OAuth 2.0 Protocol
Our authorization process uses OAuth 2.0. See the authorization section for more details. What is OAuth https://en.wikipedia.org/wiki/OAuthTLS 1.2 Requirement
For security and compliance, we require that TLS 1.2 or greater be used. It’s likely the technology you use supports this without any extra work, however, in the off-chance that it doesn’t, connection errors will differ based on the platform and libraries you’re using. In general, the error message will reference SSL/TLS explicitly, or make reference to a “handshake” error, or an “error when establishing secure communication.”. What is TLS 1.2 https://en.wikipedia.org/wiki/Transport_Layer_SecurityUser-Agent Header
All HTTP requests must include a User-Agent header. The value of the User-Agent header is up to your discretion – we recommend following convention and identifying your application product name and optionally, your product version. Only the existence of the header is required by our firewall. Requests made without this header will receive an “Error 1010: The owner of this website has banned your access based on your browser’s signature”. https://support.cloudflare.com/hc/en-us/articles/360029779472-Troubleshooting-Cloudflare-1XXX-errors#error1010 What is the User-Agent Header https://en.wikipedia.org/wiki/User_agentFormat
The uPortal360 API supports only JSON in the request and response bodies, with authorization being the only exception. Other common formats, including XML, HTML, YAML, and TXT, are not supported. As a result, all requests that include a request body must include the following header:Authorization
The uPortal360 API requires that requests are authenticated with a Bearer token via OAuth 2.0. Please see the following sections for instructions on authentication.Obtaining Credentials
Production Credentials - To receive production OAuth2 credentials, your company must work with our sales team to structure a program, and you will have to pass a code review with one of our integration specialists. For technical support, please contact us at: salesforcedev@ugafinance.com Sandbox Credentials - The Sandbox test credentials are shared across all credit application programs in our test environment and are reset daily. You can find the credentials in the request section below.Retrieve Access Token
Using your credentials, request an access token for use with the API. To do this, make a POST request to the authorization server with credentials passed as form-data. Requestaccess_token.
Use this as a Bearer Token authorization header for subsequent API
requests.
The expires_in value equals the number of seconds the access_token
will remain valid for.
Using the Access Token
To use the obtained access token with the API, send the access token in anAuthorization header with your request.
401 Unauthorized. In this case, you must obtain a new
token; this can be done by requesting a new token.
Request
Reference
This is the reference to available endpoints. All endpoints may be called in either the Staging or Production environment.Test Data
The following mock information may be used to test desired outcomes in both the Staging and Production environments.Applications
The/v1/applications endpoint is the entrypoint to the application
process, and may only be used to create (POST) and update (PATCH)
applications. Once an application has been decisioned, the application
may no longer be updated.
POST
Use the POST request to create a new application. Request Accepts an ApplicationRequeststatus is DRAFT
Returns a DraftResponse
status is PROCESS
Possible return types:
- SuccessResponse if the application was approved
- DeclinedResponse if the application was declined
- StandardResponse
PREQUAL
Request Accepts an ApplicationRequeststatus is PREQUAL
Duplicate Contract Handling
Duplicate Contract OverviewOur system doesn’t allow Duplicate contracts. To get more information on the duplicate contract use the
contract: id returned in the response, and follow this link Contract GET endpoint.Example Duplicate Contract ResponseBypassing Duplicate ContractUsing one of the Demo Cases below will bypass the duplicate check.
applicationId(path): required; identifies the application context and program.applicantSsn: required; full 9-digit SSN (hyphens/spaces allowed).- No additional fields are required; caller should only invoke after any no-hit or credit-freeze checks have passed.
- Derives the duplicate search scope from the application’s finance program and its duplicate-account rule (top-of-hierarchy, ancestor accounts, account client number, or exact program). If the rule is
N/A/empty, the program filter is empty and no duplicate will be returned. - Normalizes SSN into hyphenated and non-hyphenated forms and matches against applicant/co-applicant SSNs on active contracts (statuses not in Cancelled/VOID/Closed), returning the most recent match.
- Read-only: no persistence; returns metadata for the caller to act on.
- Response payload uses the standard
ApiResponseenvelope (data+errors).
200 OK – No duplicate found (or skip case)
409 Conflict – Duplicate found
400 Bad Request – Invalid input (e.g., missing SSN or application)
500 Internal Server Error – Unexpected failure
PATCH
Returns the same types as the POST method Use the PATCH request to edit an existing application. Only applications that meet one or more of the following criteria are eligible to be updated:- Mismatched on either the SSN or DOB
- The application status is
DRAFT - A No-Hit response was returned when processing the application
GET
A GET request may be made to retrieve a single application’s details. RequestBulk
Bulk load contracts into our system.Fields Required for Bulk Transfer
Listed below are fields that will help with a successful transfer, but are not limited to these.Bulk Transaction Required Fields
One of the following fields need to be set and not 0.GET
ThebulkRequestId variable should be the external Id of the bulk contract request object.
Request
contracts will be a list of contract external ids that were created.
POST
Requestid is the Bulk Contract Request’s External Id that was created.
Contracts
View a certain contract.GET
ThecontractExternalId variable should be the external Id of the contract.
Request
Offers V2
Offers
View the available offers for a contract.GET
GET
Path Parameters
Query Parameters
Request with a contract
Notes
- if the request is with a contract then the applicationId will return null
- only offers that have a promotional period will return with “promo” populated
- open contracts contain a minPaymentFixed property which only applies to open lines of credit
Closed Response Returns an OffersResponse
Accept
POST
Accept the application’s credit decision to continue with contract creation. RequestCharges
View, modify, or create charges for a contract.POST
Creates a new charge, or updates the most recent unsigned charge. Request Accepts a ContractChargeRequestPATCH
Updates the specified charge. Request Accepts a ContractChargeRequestPATCH
Updates the specified charge on non-charge slip contract. Request Accepts a ContractChargeRequestGET (All)
View all charges on a contract. RequestGET (Single)
View a specific charge. RequestReturns
- Only one return is permitted per charge per day.
- The maximum return amount allowed is limited to the original cash price.
- If a return has already been processed, the maximum returnable amount is the cash price minus the total of previous returns.
- If the return results in a refund, please allow 7–10 business days for processing.
POST
Create a return transaction on contract/chargeslip Request Accepts a ContractReturnRequestGET (All)
RequestGET (Single)
RequestSupport Tickets
Gets Support Ticket data and creates remarks.GET (Single)
Get Support Ticket data from a single Support Ticket. RequestGET Remarks
Returns all Private and Public (Support Ticket Notes Log) Remarks from a single Support Ticket. RequestPOST Add Remarks
Adds a Private and/or Public (Support Ticket Notes Log) Remark to a single Support Ticket.
Request
PATCH
Support Ticket status must be “Merchant Review”. Updates a given Support Ticket with given data.
Request
Patch Resolve
Support Ticket status must be “Merchant Review”. Sets Support Ticket status to “CHD Review”, sets Hold Date to today’s date, and sets Merchant Status to “Resolved”.
Request
Identity Verification
GET (All)
Get all the questions RequestGET (Single)
Gets next unanswered question RequestPOST (Answer single)
Answer question RequestFAIL or PASS
POST (Answer All)
Answer all KYC questions. RequestFAIL or PASS
Envelopes
This endpoint will void a DocuSign envelope if it hasn’t been signed. Voiding an envelope will allow Merchants and Consumers to change contract or charge details and generate a new DocuSign envelope. If an envelope has already been signed, then it may no longer be voided. To void an envelope during the origination process, make aDELETE request to /v1/contracts/{contract-id}/envelope.
To void an envelope on an additional charge, make a DELETE request to /v1/contracts/{contract-id}/charges/{charge-slip-id}/envelope.
Delete
To Void Origination EnvelopeContacts
Generate Temporary Login Link
This endpoint allows you to generate a login link to https://uportal360.com using your API credentials. The generated link is valid for 15 minutes. After 15 minutes, the endpoint should be called again to generate a new link. A link may be generated using aPOST request to /v1/contact/generateTemporaryLoginLink:
Request
GET request with a web browser using the data.url value will automatically log the user into uPortal360. The link may be re-used for up to 15 minutes.
Demo Merchant User
These credentials could be used to access uPortal360. Test User Name and PasswordPayment Methods
The payment method endpoints allow users to manage payment methods related to a particular contract. They support creating new methods, updating existing card details, deleting payment methods, retrieving stored methods such as cards or ACH, and discovering available types that can be added. Recommended Usage Sequence:- GET
- Retrieve existing payment methods and view available types and subtypes that can be added.
- POST
- Create a new payment method using supported types returned from the previous step.
- PUT
- (Optional) Update non-sensitive details of an existing card-based payment method, such as billing address or expiration date.
- DELETE
- (Optional) Remove a payment method that is no longer valid or needed.
GET
Retrieve a list of saved payment methods (e.g., cards or ACH) associated with a contract. Also returns available payment method types and subtypes that the user can add (e.g., “Bank Account”, “Card” with supported subtypes). Usage:- Used by customer portals and admin tools to:
- Display stored payment methods to the user.
- Enable adding new payment methods based on available options.
- Helps users understand what types of payment methods they can use and manage existing ones.
contractId(string) (required)- Description: The unique identifier for the contract or account that owns the payment methods.
- Use: Scopes the request to a specific customer contract, ensuring only associated payment data is retrieved.
- Example:
ABC1234LOA01,ABC1234LOA02
paymentMethods
paymentMethodId(string)- Unique identifier for the payment method.
contractId(string)- Associated contract identifier.
type(string)- Payment method type (e.g., “Credit Card”, “Bank Account”).
subType(string)- Card brand or bank account type (e.g., “Visa”, “Checking”).
lastFour(string)- Last 4 digits of card/account number.
expirationMonth/expirationYear(string)- Expiration info (only for cards).
firstName/middleInitial/lastName(string)- Cardholder or account owner info.
address1/address2/city/state/zip/country(string)- Billing address details.
autopay(boolean)- Indicates if this method is enrolled in autopay.
paymentOptions
type(string)- The general category of payment method the user can add, such as a card or a bank account.
- “Credit Card” and “Debit Card” will be combined under “Card” in
paymentOptionswhen applicable.
subTypes(string[])- Array of supported sub-types (e.g., card brands or account types).
- Invalid or missing authentication.
- User doesn’t have access to the contract account.
- Unexpected server failure.
POST
This endpoint is used to register a new payment method (such as a credit card, debit card, HSA card, or ACH bank account) to a specific contract account, which is typically associated with a customer. Once the payment method is added, it can be used for recurring or one-time bill payments. For PCI compliance, the CVV is never stored and will not be saved under any circumstance. Each time a payment is made using a stored payment method, the CVV must be re-entered to complete the transaction. Usage:- A customer portal adds a payment method when a user updates their billing preferences.
- A customer service representative uses this endpoint through an admin tool to register payment details on behalf of a customer.
- The system will validate the structure of the request.
- For cards:
- The system will tokenize the card via a PCI-compliant service.
- It may run a $0 or $1 authorization to verify validity.
- For ACH:
- The system will verify the account number via an identity service.
- If successful, the system stores the method securely and associates it with the contract account.
- For cards:
contractId(string) (required)- Description: The unique identifier for the contract or contract account to which the new payment method will be linked.
- Use: Identifies the contract account that the payment method is being attached to.
- Example:
ABC1234LOA01,ABC1234LOA02
firstName(string) (required)- Description: The payment method holder’s first legal name.
- Use: Used for billing verification and display on account records.
- Example:
John
middleInitial(string) (optional)- Description: Middle initial of the payment method holder.
- Use: May be required for identity resolution or matching existing records.
- Example:
T
lastName(string) (required)- Description: The payment method holder’s last legal name.
- Use: Used for billing verification and record keeping.
- Example:
Smith
address1(string) (required)- Description: Primary street address.
- Use: Required for AVS (Address Verification System) validation by card processors and for ACH verification.
- Example:
1234 Maple Street
address2(string) (optional)- Description: Apartment, suite, or secondary address line.
- Use: Used in AVS checks.
- Example:
Apt 123
city(string) (required)- Description: City for the billing address.
- Use: Used in AVS checks.
- Example:
Springfield
state(string) (required)- Description: State or province for the billing address.
- Use: Used in AVS checks.
- Example:
IL
zip(string) (required)- Description: ZIP/postal code.
- Use: Required for AVS (Address Verification System) validation by card processors and for ACH verification.
- Example:
62704
country(string) (required)- Description: The billing address associated with the payment method.
- Use: Used in AVS checks.
- Example:
UNITED STATES
ach
- Note: Only one of
achorcardshould be populated. accountType(string) (required)- Description: Indicates the type of bank account:
- “CHECKING”
- “SAVINGS”
- Use: Some financial services use different processing rules or verifications based on account type.
- Example:
CHECKING
- Description: Indicates the type of bank account:
routingNumber(string) (required)- Description: The ABA routing number (also known as the bank routing number) that identifies the financial institution where the account resides. Exactly 9 digits in the U.S.
- Use: Used to route the ACH transaction to the correct bank.
- Example:
021000021
accountNumber(string) (required)- Description: The bank account number to be used for ACH transactions. Typically 6–17 digits.
- Use: Identifies the specific bank account from which ACH payments will be pulled.
- Example:
123456789012
card
- Note: Only one of
cardorachshould be populated. cardType(string) (required)- Description: Indicates the type of card:
- “CREDIT CARD”
- “DEBIT CARD”
- “HSA”
- Use: Indicates the functional category of the card being added as a payment method.
- Example:
CREDIT CARD
- Description: Indicates the type of card:
cardNumber(string) (required)- Description: The full 15–16 digit card number (PAN).
- Use: Value will be encrypted and tokenized, never saved in plain text.
- Example:
1234 1234 1234 1234,1234 123456 12345
cardBrand(string) (required)- Description: The brand or network of the card:
- “VISA”
- “MASTERCARD”
- “AMEX”
- “DISCOVER”
- Use: Identifies the card brand.
- Example:
VISA
- Description: The brand or network of the card:
cvv(string) (required)- Description: The 3 or 4-digit card verification value (CVV2 or CVC). CVV is never stored and will not be saved under any circumstance.
- Use: Used for security and fraud checks during authorization.
- Example:
1231234
cardExpiration(string) (required)- Description: Indicates card expiration in MMYY format.
- Use: Required for authorization and to ensure card validity.
- Example:
0126,1227
paymentMethodId(string)- Unique identifier for the payment method.
- Missing required fields or invalid format.
- Invalid or missing authentication.
- User doesn’t have access to the contract account.
- Invalid card or bank account details.
- The payment method type cannot be added to this account at this time.
- For example, if a user submits a payment method and the system detects through verification that it is a PrePaid card, and the contract is set up to not allow PrePaid, the system will return an error.
- Unexpected server failure.
PATCH
Updates non-sensitive metadata of an existing card-based payment method (e.g., expiration date, billing address, name).- Cannot be used for:
- Updating ACH methods - must create a new one.
- Changing card number - must create a new one.
- Update billing address or refresh card expiration details.
- Used by customer portals or admin tools when the card is still valid but associated information changes.
contractId(string) (required)- Description: The unique identifier of the contract or contract account that owns the payment method.
- Use: Used to scope the update to a specific customer account. Ensures the update is authorized and routed to the correct context.
- Example:
ABC1234LOA01,ABC1234LOA02
paymentMethodId(string) (required)- Description: The unique identifier for the specific card payment method to be updated.
- Use: Determines which existing payment method record to update. Must refer to a card method, or the request will be rejected.
- Example:
ABC1234LOA01-A12
firstName(string) (required)- Description: The payment method holder’s first legal name.
- Use: Used for billing verification and display on account records.
- Example:
John
middleInitial(string) (optional)- Description: Middle initial of the payment method holder.
- Use: May be required for identity resolution or matching existing records.
- Example:
T
lastName(string) (required)- Description: The payment method holder’s last legal name.
- Use: Used for billing verification and record keeping.
- Example:
Smith
address1(string) (required)- Description: Primary street address.
- Use: Required for AVS (Address Verification System) validation by card processors and for ACH verification.
- Example:
1234 Maple Street
address2(string) (optional)- Description: Apartment, suite, or secondary address line.
- Use: Used in AVS checks.
- Example:
Apt 123
city(string) (required)- Description: City for the billing address.
- Use: Used in AVS checks.
- Example:
Springfield
state(string) (required)- Description: State or province for the billing address.
- Use: Used in AVS checks.
- Example:
IL
zip(string) (required)- Description: ZIP/postal code.
- Use: Required for AVS (Address Verification System) validation by card processors and for ACH verification.
- Example:
62704
country(string) (required)- Description: The billing address associated with the payment method.
- Use: Used in AVS checks.
- Example:
UNITED STATES
card
cardExpiration(string) (required)- Description: Indicates card expiration in MMYY format.
- Use: Required for authorization and to ensure card validity.
- Example:
0126,1227
- Payment method updated successfully.
- Missing required fields or invalid format.
- Invalid or missing authentication.
- User doesn’t have access to the contract account.
- User doesn’t have access to this payment method.
- Invalid card details.
- Unexpected server failure.
DELETE
Removes a payment method (ACH or card) from active use on a contract. The deletion is irreversible and recovery is not guaranteed. Usage:- Called when a customer or admin removes a saved payment method.
- Can be used to manage expired, unused, or revoked cards/accounts.
contractId(string) (required)- Description: The unique identifier of the contract or contract account that owns the payment method.
- Use: Scopes the delete operation to the correct contract account, ensuring that only authorized and context-specific deletions occur.
- Example:
ABC1234LOA01,ABC1234LOA02
paymentMethodId(string) (required)- Description: The unique identifier for the specific card or ACH payment method to be deleted.
- Use: Specifies which existing ACH or card payment method to delete. Must exist and belong to the contract, or the request will be rejected.
- Example:
ABC1234LOA01-A12
- Payment method deleted successfully.
- Missing required fields or invalid format.
- Invalid or missing authentication.
- User doesn’t have access to the contract account.
- User doesn’t have access to this payment method.
- Unexpected server failure.
Payments
The payment endpoint allows users to initiate a charge using a previously stored and authorized payment method, enabling seamless transactions without re-entering payment details. Recommended Usage Sequence:- GET Payment Methods
- Retrieve the list of existing payment methods and available options for adding new ones.
- POST Payment Methods (if needed)
- Add a new payment method if the user has not previously stored one.
- POST
- Initiate a one-time payment using a stored and authorized payment method.
- Note: The CVV must be re-entered at the time of payment, as it is never stored for PCI compliance.
POST
This API endpoint is used to initiate a payment on behalf of a user using a previously stored and authorized payment method. It enables systems to process charges without requiring users to re-enter their payment information. Usage:- A client application (web, mobile, or backend service) needs to charge a user for a specific transaction.
- The payment method has already been securely stored (e.g., via tokenization or encryption) and is referenced by its unique ID.
- When the payment is processed successfully, a receipt is automatically emailed to the user using the email address on file associated with the provided
contractId.- The receipt includes:
- Payment amount (in USD)
- Date/time of payment
- Payment method used (masked details)
- Confirmation number, transaction ID, or order reference number
- Merchant name
- The receipt includes:
contractId(string) (required)- Description: The unique identifier for the contract or contract account to which this one-time payment is being made.
- Use: Tells the system where to apply the payment.
- Example:
ABC1234LOA01,ABC1234LOA02
cvv(string) (required)- Description: The 3 or 4-digit card verification value (CVV2 or CVC).
- Use: Used for security and fraud checks.
- Example:
1231234
paymentAmount(number) (required)- Description: The monetary value to be charged for this transaction. Must be a positive number and formatted to two decimal places.
- Use: This is the actual charge amount in USD.
- Example:
25.00
paymentMethodId(string) (required)- Description: A unique identifier for the payment method (e.g., credit card, ACH account) that has been stored and authorized for use.
- Use: This ID is usually obtained from a prior call where the user added their payment method securely.
- Example:
ABC1234LOA01-A12
- Payment processed successfully.
- Payment failed due to a decline reason.
- Missing or invalid fields.
- Invalid or missing authentication.
- User doesn’t have access to the contract account.
- Unauthorized use of the payment method.
- Payment method is not available.
- Unexpected server failure.
Webhook
Application Status Change
- Gives visibility to the progression of a Credit Application
Expected Responses
- UAS expects to receive 200 when post is successful
- UAS expects to receive 500 if not successful or not accepted by the receiver.
Payload: Headers
Content-Type: application/json
Payload: Event Examples
Newly Drafted ApplicationContract Status Change
- Gives visibility to the status changes of a contract.
Expected Responses
- UAS expects to receive 200 when post is successful
- UAS expects to receive 500 if not successful or not accepted by the receiver.
Payload: Headers
Content-Type: application/json
Payload: Event Examples
Went Past DueSupport Ticket Status Change
- Gives visibility to the progression of a Support Ticket.
Expected Responses
- UAS expects to receive 200 when post is successful
- UAS expects to receive 500 if not successful or not accepted by the receiver.
Payload: Headers
Content-Type: application/json