Accept.blue is an API-first payment platform, and GiveWP is one of the most common ways WordPress sites take money. This guide connects the two, from credentials through testing to going live.
For background on the platform and the other integrations available, see the Accept.blue overview for WordPress.
Before you begin
- An approved Accept.blue account with your gateway credentials.
- WordPress running GiveWP, kept up to date.
- HTTPS across the whole site. Browsers warn users before they reach an insecure form, and gateways refuse to process on one.
- The Accept.blue plugin for GiveWP.
Get the credentials before installing anything. A gateway switched on but not configured shows customers a payment option that fails, which costs more than waiting a day.
Step 1: Install the plugin
Upload the ZIP under Plugins → Add New → Upload Plugin and activate it. An Accept.blue section appears in your GiveWP payment settings. Install on staging first if you have it.
Step 2: Add your credentials
Paste the credentials into the plugin settings and keep test and live values clearly separated in a password manager. The sets look alike, and leaving test keys in place at launch is the single most common launch failure.
Step 3: Configure a GiveWP donation form
Name the method something customers recognize. “Credit or debit card” outperforms a processor name that means nothing to a buyer. Add a short description only if something genuinely needs explaining.
Choose between immediate capture and authorize-then-capture. Immediate capture suits digital delivery; authorize-then-capture suits physical goods, letting you take payment when the item ships and avoiding refunds on stock you cannot fulfil.
Step 4: Test every path
Switch to test mode and work through a GiveWP donation form as a customer:
- An approved card completes and records the correct amount.
- A declined card shows a clear message rather than a blank page or raw error code.
- Totals match exactly, including tax and shipping.
- Receipts reach the customer and you.
- Abandoning mid-payment leaves no order marked paid.
Deliberately test a decline. Most post-launch complaints concern unclear refusal messages, not failed charges.
Step 5: Go live
Replace the test credentials, turn test mode off, then process one small real payment with your own card and refund it. That transaction proves the entire chain, from a GiveWP donation form to funds landing in your account.
Understanding your statement
If you are on interchange-plus pricing, your statement itemizes the network cost and the provider margin separately rather than showing one blended percentage. It looks more complicated and tells you more: you can see which card types cost you most and whether your effective rate is drifting.
Reconcile settlement against your GiveWP records regularly. Payouts arrive in batches with fees usually deducted first, so a deposit will not match the day takings exactly. Knowing what normal looks like is what lets you notice a genuine problem.
Refunds and disputes
Issue refunds inside WordPress where the plugin supports it, so your records and the gateway stay in step. Refunding only in the provider portal leaves WordPress showing the original amount.
For disputes, keep the order record, delivery evidence and authorization response together. Dispute windows are short and evidence assembled afterwards rarely convinces. A billing descriptor customers recognize on a statement prevents a real share of disputes from people who simply do not remember the purchase.
Troubleshooting
The method is missing at checkout. Check the plugin is active, the gateway enabled, and that currency or country rules are not excluding the order.
Everything declines in test mode. Usually live credentials against the test endpoint, or the reverse.
Payment taken but order unpaid. The gateway response is not reaching WordPress. Check host firewalls and security plugins that filter incoming requests.
Other integrations
Using more than one plugin? The Accept.blue overview covers every available integration.
Get the plugin
The Accept.blue Payment Gateway for GiveWP is available from wpayo with updates and support included.
Reducing checkout abandonment
Once payments work, the remaining money is usually lost before the payment step rather than during it. Three changes in GiveWP tend to pay for themselves.
Ask for less. Every additional field costs completions. Collect what you need to fulfil and charge; anything else can be asked for later.
Show the full total early. A price that grows at the final step is one of the best-documented causes of abandonment. Surface shipping and tax before the last click.
Allow guest checkout. Forcing account creation before purchase loses buyers who would happily have created one afterwards.
Keeping the integration healthy
Update the gateway plugin promptly, since payment plugins track API changes and an outdated one can break when an endpoint is retired. Re-test after major GiveWP or WordPress updates. Monitor for failures instead of waiting for customers to report them, because a run of declines usually signals a configuration problem rather than coincidence.
Frequently asked questions
Can we run subscriptions through GiveWP?
Repeat billing depends on stored tokens plus whatever subscription capability GiveWP offers, sometimes through an extra extension. Confirm both before advertising a subscription, because withdrawing the option later costs more goodwill than never offering it.
What happens if our site goes down mid-payment?
A payment authorized at the gateway stands even if the site cannot record it, which is why periodic reconciliation between gateway records and GiveWP matters.
Can we keep a second gateway as a fallback?
Yes. GiveWP can offer several payment methods, so one account problem does not halt sales.
Does the payment step slow the checkout down?
The gateway call takes a fraction of a second. Slow checkouts are almost always caused by page weight, hosting or plugin bloat rather than the payment request itself.
Leave a Reply