Ellipse Gradient for Header

Global Payments Integration Guide

Connect Global Payments payment-processing APIs with commerce, finance, and enterprise applications using Martini workflows, REST APIs, callbacks, and secure data transformation.

Global Payments integration options at a glance

Global Payments primarily integrates through product-specific REST APIs, application credentials, merchant credentials, and request-authentication headers. Selected products may provide notification or callback capabilities for transaction and payment events, while settlement, deposit, reconciliation, and reporting services may support batch resources or file exchange. Martini can consume the applicable REST endpoints, expose an internal API for commerce and finance applications, validate supported callbacks, transform payment data, and orchestrate scheduled synchronization. Authentication, object names, notification coverage, and file availability vary across Global Payments products and regions, so the selected API product must be confirmed before implementation.

Integration pointSupported by Global Payments?Common use casesHow Martini supports it
REST APIsYesCreate, authorize, capture, void, refund, and retrieve payment transactions; query merchants, disputes, settlements, or reporting data where exposed by the selected product.Martini can consume Global Payments REST endpoints from workflows, map request and response payloads, apply validation and business rules, and expose normalized APIs to other applications.
Webhooks / outbound callbacksLimitedSelected Global Payments products may provide notifications for transaction, payment, dispute, or settlement events. Event coverage and delivery behavior are product-specific.Martini can expose an API endpoint for supported callbacks, validate signatures or shared secrets, deduplicate events, acknowledge promptly, and process downstream updates asynchronously.
Bulk / async / batch APIsLimitedSettlement, deposit, reconciliation, and reporting services may provide batch-oriented or asynchronous resources, depending on product and merchant configuration.Martini can schedule batch retrieval, maintain cursors or synchronization timestamps, transform large result sets, and route reconciliation exceptions for review.
File / attachment APIsLimitedFile-based settlement or reconciliation exports may be available for selected processing services. Dispute evidence or attachment support must be confirmed for the selected product.Martini can orchestrate approved file exchanges and transform available reporting data, but the exact file interface and attachment model must be confirmed before implementation.
AuthenticationYesGlobal Payments products may use application identifiers, API keys, secrets, merchant credentials, request headers, or product-specific OAuth 2.0 arrangements.Martini stores credentials and environment-specific endpoint settings in secrets or configuration, applies the required request authentication, and separates sandbox from production access.
Product SDKsLimitedGlobal Payments publishes SDKs or client libraries for some API products and programming languages, particularly where product-specific request handling is complex.Martini can generally consume the underlying REST API directly; an SDK is not inherently required. Custom JVM-compatible logic may be considered only when the documented API behavior requires it.
GraphQL APIsNot confirmedNo verified GraphQL API was identified for the primary Global Payments developer platform.Martini supports GraphQL consumption generally, but a Global Payments GraphQL integration should not be designed unless the selected product documentation confirms one.
Database accessNot applicableGlobal Payments does not expose direct database access for customer integrations. Approved APIs or reporting and file interfaces should be used instead.Martini can write normalized results to an enterprise database when required, but it should not connect directly to Global Payments databases.

How Global Payments exposes data and business events

Global Payments REST APIs

REST APIs are the primary Global Payments integration mechanism, but available resources and schemas vary between Global Payments API, Genius, Heartland, regional, and other product families. Typical operations include transaction authorization, capture, void, refund, status retrieval, merchant queries, disputes, settlements, and reporting.

Martini implementation pattern

Martini implementation pattern: Martini receives a request or scheduled trigger, validates payment data and identifiers, applies product-specific authentication, calls the selected Global Payments REST endpoint, maps the response to a canonical model, and routes business outcomes separately from technical failures.

Implementation sequence

Receive an API request or scheduled workflow trigger
Validate the merchant context, amount, currency, and request identifier
Transform the source payment model into the selected Global Payments request schema
Call the authenticated Global Payments REST endpoint
Map the response to a canonical transaction, refund, dispute, or settlement model
Persist correlation identifiers and route success, decline, and technical failure outcomes

Global Payments callbacks

Selected Global Payments products may provide notification or callback capabilities for selected transaction, payment, dispute, or settlement events. Callback availability, payload completeness, delivery guarantees, and signature requirements must be confirmed for the selected product.

Martini implementation pattern

Martini implementation pattern: Martini exposes a controlled API endpoint, validates the callback signature or shared secret, records the event identifier, deduplicates repeated notifications, acknowledges promptly, and performs longer-running synchronization asynchronously. If a callback contains only an identifier, the workflow retrieves the current resource through the REST API.

Implementation sequence

Receive the supported Global Payments callback
Validate the signature, authorization data, timestamp, or shared secret
Record the event identifier and reject duplicate deliveries
Retrieve the current resource when the callback contains only an identifier
Map the event and resource data to the downstream model
Acknowledge the callback and process downstream updates asynchronously

Global Payments batch and reporting data

Settlement, deposit, reconciliation, and reporting capabilities may expose batch-oriented resources or downloadable files for selected services and merchant arrangements. These capabilities are not universal across Global Payments products.

Martini implementation pattern

Martini implementation pattern: Martini schedules a reconciliation workflow, retrieves the approved batch or reporting resource, follows pagination or continuation information, normalizes amounts and dates, matches provider identifiers to internal transactions, and records unresolved differences for review.

Implementation sequence

Start the reconciliation workflow on an approved schedule
Retrieve the selected settlement, deposit, batch, or reporting resource
Follow the documented cursor, page, or continuation mechanism
Normalize amounts, currencies, dates, fees, and provider identifiers
Match settlement data to internal transactions or orders
Write reconciliation results and route unmatched items for investigation

Global Payments file exchange

File-based settlement or reconciliation exports may be available for particular processing services or merchant arrangements. File support and dispute attachment capabilities must be verified with the applicable Global Payments documentation or account team.

Martini implementation pattern

Martini implementation pattern: Martini retrieves or receives an approved file through the documented interface, validates its format and expected period, transforms rows into canonical settlement or reconciliation objects, and writes results to the target finance system. Unsupported or malformed files are quarantined for review.

Implementation sequence

Retrieve or receive the approved Global Payments file
Validate the file source, format, period, and expected content
Parse rows into settlement, deposit, or reconciliation objects
Transform monetary and identifier fields into the target model
Write valid results to the finance or operations system
Quarantine malformed files and record processing diagnostics

Common Global Payments integration patterns

Pattern 1: Orchestrate order payments

When to use this pattern

Use this pattern when Shopify, Salesforce, Zuora, or an internal order service needs to initiate an authorization or capture without embedding Global Payments-specific credentials and request logic in the commerce application.

Integration direction
Shopify
Martini
Global Payments
Example Mapping
Global Payments FieldCanonical FieldTarget Field
order.idorderReferenceorder reference
payment.amounttransactionAmounttransaction amount
payment.currencycurrencyCodecurrency
payment.tokentokenizedPaymentMethodpayment method token
Martini implementation pattern

Martini exposes an internal payment API or receives the commerce request through a workflow, validates amount and currency, applies merchant-specific rules, and transforms the request into the selected Global Payments REST schema. It persists the request identifier and correlation data, distinguishes declines from technical failures, and avoids retrying a payment when a timeout leaves the outcome unknown until the transaction is queried.

Martini capabilities used
  • workflows
  • API consumption
  • API exposure
  • data mapping
  • business rules
  • secure environment configuration
  • error handling

Pattern 2: Synchronize payment status

When to use this pattern

Use this pattern when downstream order, customer-service, or finance applications need current authorization, capture, refund, void, or transaction status and callback coverage is unavailable or incomplete.

Integration direction
Global Payments
Martini
Salesforce
Example Mapping
Global Payments FieldCanonical FieldTarget Field
transaction.idproviderTransactionIdGlobal Payments transaction ID
transaction.statuspaymentStatuspayment status
transaction.amountsettledAmountamount
transaction.updatedAtlastProviderUpdatelast payment update
Martini implementation pattern

A scheduled Martini workflow retrieves changed transactions using the product's pagination, cursor, or timestamp mechanism, maps provider statuses to the target application's status model, and applies reconciliation rules for pending, successful, failed, refunded, and voided payments. It stores a checkpoint, uses bounded concurrency, and retries only safe transient failures.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • pagination and checkpoint handling
  • data mapping
  • business rules
  • retry and error handling

Pattern 3: Govern refunds and voids

When to use this pattern

Use this pattern when an ERP, order-management service, or commerce application requests refunds or voids and the business needs consistent validation, authorization, and duplicate protection.

Integration direction
Oracle NetSuite
Martini
Global Payments
Example Mapping
Global Payments FieldCanonical FieldTarget Field
invoice.idorderReferenceorder or payment reference
refund.amountrequestedRefundAmountrefund amount
originalTransactionIdproviderTransactionIdoriginal transaction ID
refund.reasonrefundReasonrefund or reason field
Martini implementation pattern

Martini receives the refund request through an API, validates the original transaction, remaining refundable amount, currency, merchant permissions, and idempotency key, then calls the appropriate Global Payments endpoint. The workflow maps the result back to the source system and queries the provider before retrying when the initial response is uncertain.

Martini capabilities used
  • API exposure
  • workflows
  • validation
  • business rules
  • data mapping
  • idempotency handling
  • error handling

Pattern 4: Reconcile settlements and disputes

When to use this pattern

Use this pattern when finance or operations teams need to match Global Payments deposits, settlement batches, fees, or disputes with ERP records and service cases.

Integration direction
Global Payments
Martini
SAP S/4HANA
Example Mapping
Global Payments FieldCanonical FieldTarget Field
settlement.depositIdproviderDepositIdexternal deposit ID
settlement.netAmountnetSettlementAmountcleared amount
settlement.feesprocessingFeespayment fees
dispute.statusdisputeStatuscase or dispute status
Martini implementation pattern

Martini schedules retrieval of available settlement, deposit, reporting, or dispute resources, follows continuation tokens, normalizes amounts and dates, and matches provider identifiers to ERP transactions. Unmatched deposits, unsupported statuses, and incomplete data are routed to an exception path while completed batches are checkpointed for idempotent reruns.

Martini capabilities used
  • scheduled workflows
  • batch processing
  • data mapping
  • business rules
  • API consumption
  • exception routing
  • monitoring

Applications commonly integrated with Global Payments

Global Payments can be connected to commerce, subscription, finance, and service applications through Martini. These are typical enterprise architecture patterns; the exact payment product, credentials, supported operations, and notification model should be confirmed for the relevant Global Payments account.

Application Scenario Direction Martini Pattern
Shopify Send order payment requests to Global Payments and synchronize authorizations, captures, refunds, and transaction status with commerce orders. Shopify → Martini → Global Payments Martini exposes or consumes an order-payment API, validates amount and currency, maps Shopify payment data to the selected Global Payments REST schema, and returns a normalized result. Status reconciliation and safe retry logic handle delayed or unknown outcomes.
Salesforce Make payment outcomes available alongside Accounts, Contacts, Orders, and service cases while centralizing payment processing rules. Salesforce → Martini → Global Payments A Martini workflow receives payment or refund requests from Salesforce, applies transaction and refund rules, calls Global Payments, and maps the response into Salesforce fields. Supported callbacks or scheduled polling can update transaction and dispute status.
Oracle NetSuite Reconcile transactions, refunds, fees, deposits, and settlement information with invoices and cash records. Global Payments → Martini → Oracle NetSuite Scheduled Martini workflows retrieve available transaction, settlement, deposit, or reporting data, normalize monetary values, match records using transaction identifiers, and write reconciliation results to NetSuite. Exceptions are routed separately for review.
SAP S/4HANA Post payment and settlement information to finance processes and initiate approved refund or payment actions. SAP S/4HANA → Martini → Global Payments Martini maps SAP payment instructions into Global Payments requests, applies merchant and currency validation, and maps responses back to SAP. Settlement workflows support reconciliation, while transient provider errors are retried without repeating unsafe payment operations.
Microsoft Dynamics 365 Synchronize order payment status, refunds, and finance reconciliation information across customer and financial processes. Microsoft Dynamics 365 → Martini → Global Payments Martini orchestrates requests from Dynamics 365 to Global Payments and maps status changes back to the relevant order or finance object. A scheduled workflow can reconcile transactions when product-specific callbacks are unavailable.
Zuora Coordinate subscription billing outcomes with payment authorization, capture, refunds, and transaction status. Zuora → Martini → Global Payments A Martini API receives billing payment requests from Zuora, transforms them for the selected Global Payments product, persists correlation identifiers, and returns normalized authorization or failure outcomes. Pending transactions are reconciled by callback or polling where supported.
ServiceNow Create payment-related support cases and route dispute, settlement, or exception information to operational teams. Global Payments → Martini → ServiceNow Martini retrieves or receives selected dispute, settlement, and payment exceptions, maps them to ServiceNow cases, and includes transaction identifiers and reconciliation context. Duplicate detection and controlled updates prevent repeated case creation.

How to build a Global Payments integration in Martini

Objective

Establish product-specific Global Payments connectivity with separate sandbox and production settings while keeping credentials outside workflow definitions.

Instructions in Martini

  • Identify the exact Global Payments product, region, base URL, API version, and merchant context
  • Configure the documented API key, secret, merchant credential, request header, or other authentication method
  • Store credentials and signing material in Martini secrets or environment configuration
  • Confirm permissions for transactions, disputes, settlements, reporting, and callbacks

Objective

Select the event, API, or schedule that starts each integration flow based on the capabilities of the selected Global Payments product.

Instructions in Martini

  • Use an exposed Martini API for payment, refund, or void requests
  • Receive supported Global Payments callbacks through a controlled Martini endpoint
  • Use a scheduler to poll transactions, disputes, settlements, or reporting resources when callbacks are unavailable
  • Use a file trigger or approved retrieval process only when the merchant arrangement supports file exchange

Objective

Receive or retrieve the required Global Payments object and preserve provider identifiers needed for correlation and reconciliation.

Instructions in Martini

  • Validate callback signatures, shared secrets, timestamps, or authorization information where applicable
  • Retrieve the full transaction or dispute when a notification contains only an identifier
  • Follow documented pagination, cursor, continuation, or batch mechanisms
  • Persist request identifiers, provider transaction IDs, event IDs, and synchronization checkpoints

Objective

Coordinate provider calls, validation, business decisions, target updates, and exception handling in a maintainable Martini workflow.

Instructions in Martini

  • Separate payment declines and validation failures from technical provider errors
  • Use conditional routing for pending, successful, refunded, voided, disputed, and failed outcomes
  • Apply bounded concurrency for reconciliation and reporting workloads
  • Use asynchronous processing for longer downstream work after acknowledging callbacks

Objective

Convert commerce, finance, and service payloads into the schema required by Global Payments and downstream systems.

Instructions in Martini

  • Map order, invoice, merchant, payment, transaction, dispute, and settlement identifiers explicitly
  • Normalize currency, monetary precision, dates, statuses, and provider-specific codes
  • Avoid floating-point arithmetic for financial calculations
  • Mask sensitive payment data in logs and error payloads

Objective

Protect payment operations through validation, idempotency, authorization, and product-specific business rules.

Instructions in Martini

  • Validate amount, currency, merchant permissions, refund limits, and required identifiers
  • Use the supported idempotency or request-correlation mechanism for charge, capture, and refund operations
  • Query Global Payments before retrying a request with an unknown outcome
  • Reject duplicate callbacks and prevent duplicate downstream updates

Common Global Payments data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
TransactionsRepresent authorizations, sales, captures, refunds, voids, and transaction status results.Shopify, Salesforce, Oracle NetSuite, SAP S/4HANA, Microsoft Dynamics 365, and internal order servicesMartini validates amounts, currencies, identifiers, and idempotency values; calls the selected REST resource; then maps responses to a canonical transaction model with correlation and status data.
Payment methodsRepresent card or tokenized payment credentials used to initiate transactions.Shopify, Salesforce, Zuora, and internal payment servicesMartini should prefer tokenized or hosted payment patterns, minimize sensitive data, mask values in logs, and pass only fields permitted by the selected Global Payments product and PCI controls.
MerchantsRepresent merchant accounts or processing entities associated with payment activity, credentials, and permissions.Finance platforms, payment administration services, and internal configuration storesMartini uses merchant context to select credentials, endpoints, and business rules without embedding secrets in workflow definitions.
OrdersProvide the commercial order or payment context associated with a transaction where supported by the selected API.Shopify, Salesforce, Oracle NetSuite, SAP S/4HANA, and Microsoft Dynamics 365Martini maps order identifiers, totals, currencies, and customer context into the payment request and preserves the relationship between the order and Global Payments transaction.
DisputesRepresent chargebacks or payment disputes, including status, reason, deadlines, and supporting evidence where available.Salesforce, ServiceNow, Oracle NetSuite, SAP S/4HANA, and finance operations platformsMartini retrieves or receives supported dispute data, normalizes statuses and deadlines, creates or updates downstream cases, and routes exceptions for manual review.
Deposits or settlementsRepresent funding, settlement, batch, deposit, and reconciliation information used to match processed payments with cash activity.Oracle NetSuite, SAP S/4HANA, Microsoft Dynamics 365, and finance data storesScheduled workflows retrieve available settlement data, preserve provider identifiers, map fees and amounts, match deposits to transactions, and record unresolved differences.

Authentication and security considerations

Product-specific authentication

Global Payments authentication varies by product, region, merchant account, and environment. Implementations may use application identifiers, API keys, secrets, merchant credentials, request headers, or product-specific OAuth 2.0 arrangements.

Credential protection

  • Store credentials, merchant identifiers, signing secrets, and endpoint settings in Martini secrets or environment configuration.
  • Separate sandbox and production credentials and permissions.
  • Confirm account permissions for transactions, settlements, disputes, reporting, and callbacks.

Payment data protection

  • Prefer hosted payment or tokenized payment methods supported by the selected Global Payments product.
  • Avoid passing full card numbers or security codes through Martini unless the architecture and compliance controls explicitly permit it.
  • Mask sensitive values in logs, error payloads, and operational records.

Callback verification

For supported callbacks, validate the documented signature, shared secret, authorization header, timestamp, replay controls, or IP restrictions before processing the event.

Operational considerations for Global Payments integrations

Idempotency and unknown outcomes

Payment operations must distinguish definite failures from timeouts where the provider may have processed the request. Persist stable request identifiers and query the transaction before retrying an uncertain authorization, capture, or refund.

Amounts and currencies

Validate currency codes, minor-unit or decimal representation, refund limits, merchant restrictions, and maximum amounts. Do not use floating-point arithmetic for financial calculations.

Pagination and rate limits

Transaction, dispute, settlement, and reporting resources may be paginated and may have different rate limits. Use cursors or continuation tokens where available, bounded concurrency, and exponential backoff for transient throttling or provider errors.

Callbacks and reconciliation

Callback support is product-specific and may provide only selected events or identifiers. Use scheduled polling or approved reporting resources when required events are unavailable, and checkpoint completed synchronization periods.

Product and schema variation

Confirm the API product, region, base URL, version, resource names, authentication model, supported currencies, notification behavior, settlement resources, and sandbox behavior before combining schemas from Global Payments, Heartland, Genius, or other platforms.

Testing and monitoring

Test declines, duplicate requests, malformed data, throttling, timeouts, callbacks, pending statuses, refunds, disputes, and settlement reconciliation in the appropriate sandbox. Monitor workflow logs, correlation identifiers, retry outcomes, and unmatched financial records.

Why use Martini instead of scripts or point-to-point integrations?

Centralized orchestration

Martini provides a controlled workflow layer between Global Payments and commerce, finance, subscription, and service applications. This keeps provider-specific authentication, request models, status handling, and payment rules out of every consuming application.

Reusable integration assets

Teams can expose normalized APIs, reuse workflows, and apply consistent mappings and business rules across authorization, capture, refund, dispute, and settlement processes.

Reliable processing

Martini supports scheduled and event-driven workflows, validation, conditional routing, asynchronous processing, checkpointing, and structured error handling. These capabilities help distinguish payment declines from transient technical failures and reduce duplicate operations.

Maintainability and change control

Global Payments product families and regional APIs can differ. A Martini integration can isolate those differences behind reusable workflows and APIs, making product-specific schema changes easier to test, monitor, and deploy than scattered scripts or point-to-point implementations.

Frequently asked questions

How can Global Payments be integrated with enterprise systems?

Global Payments is primarily integrated through product-specific REST APIs, application or merchant credentials, and request-authentication requirements. Selected products may also provide callbacks, batch or reporting resources, and file-based settlement interfaces. The exact objects, authentication model, and notification coverage depend on the Global Payments product and region.

Can Martini integrate with Global Payments?

Yes. Martini can consume the applicable Global Payments REST APIs, expose an internal API for payment operations, orchestrate scheduled synchronization, and receive supported product-specific callbacks. Martini can also map transactions, refunds, disputes, settlements, and reporting data into enterprise applications.

Do I need a connector to integrate Global Payments with Martini?

No dedicated Global Payments connector is required. Martini can integrate using Global Payments native REST APIs, supported callbacks or notifications, approved reporting or batch resources, file interfaces, and the authentication methods documented for the selected product.

Is there any extra Lonti cost to integrate Global Payments with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Global Payments. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Global Payments, cloud infrastructure, or other third-party systems based on subscription, transaction volume, and deployment model.

Which Global Payments integration methods should a new implementation use?

REST APIs are the primary recommended mechanism for current integrations. Product-specific callbacks can be used for selected events when confirmed, while scheduled REST polling, batch resources, reporting endpoints, or approved files can support reconciliation. No verified GraphQL or current recommended SOAP API was identified for the primary developer platform.

Can Martini receive Global Payments webhooks or callbacks?

Martini can expose an API endpoint for supported Global Payments callbacks. Notification coverage is product-specific rather than universal, so the implementation must confirm available events, payload contents, delivery behavior, signature validation, replay protection, and retry semantics for the selected API.

How should Global Payments synchronization and duplicate payments be handled?

Use the idempotency or request-correlation facility supported by the selected Global Payments API, persist provider identifiers, and maintain a cursor, continuation token, or synchronization timestamp for scheduled retrieval. When a timeout creates an unknown outcome, query the transaction before retrying. Callback processing should also be idempotent.

How does Martini handle Global Payments mapping, errors, and an API façade?

Martini can map Global Payments payloads into canonical transaction, refund, dispute, settlement, and payment models, apply amount and currency validation, and route declines separately from technical failures. It can expose a normalized REST API that hides provider-specific details and credentials. Workflows can implement bounded retries for transient failures, while unknown payment outcomes require status lookup rather than blind repetition.

Related Martini documentation

APIs

Workflows

Security

Data

Operations

Connect Global Payments with Martini

Use Martini to integrate Global Payments REST APIs, supported callbacks, and reconciliation processes with the enterprise systems that manage orders, customers, finance, and operations.

EXPLORE MARTINI
BOOK A DEMO