> For the complete documentation index, see [llms.txt](https://apidocs.arionbanki.is/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://apidocs.arionbanki.is/b2b-2013-schema/b2b-services/b2b-payment-service/use-cases.md).
# Use Cases
### Create a batch payment
Users can create a batch payment in their accounting system and send it to the B2B payment service. The batch is then created in the Arion online bank and is visible on the “Batch Payments” page. The user receives a unique ID for the batch and can go to the Arion online bank to view, delete, or confirm (execute) the payment batch. It is not possible to edit the batch in the online bank, so errors must be corrected in your account system. After correcting the errors, delete the old batch from the online bank and send the new one in via the B2B service. It is possible to book batch payments in the online bank even though it has errors. In that case, you will receive a confirmation for the payments that were booked as well as the payments that resulted in an error. After analyzing the errors, you can correct them in your accounting system and resubmit them, as described above.
### Initiate a batch payment without using the online bank to confirm payments
Users can create a batch payment in their accounting system that does not need to be confirmed in the online bank. To do this, the user creating the batch must be configured as a “straight through” user. To configure a user as a “straight through” user, the company’s power of attorney must contact Arion’s corporate finance division and request to have this functionality configured (see chapter 4.2 for more information). After a batch is created, it is confirmed (executed) automatically with the straight through process. A unique identifier is returned by the function and information on the batch can be fetched using the *GetPaymentsResult* (6.1) function, with the unique identifier as an input.
### Cancel creation of batch if errors are present
Users can create a batch payment in their accounting system that is configured so the batch will not be created if an error is present. To do this, the *RollbackOnError* parameter in the *DoPayments* (6.1) function should be set to *true.* If errors are present and the batch is not created, the first error in the batch will be returned.
#### RollbackOnError payment process (not using “Straight through”)
**The steps below describe the RollbackOnError processes when there are errors present.**
**RollbackOnError = True**
1. User creates a batch payment.
2. Batch is error checked.
3. There are errors present, batch is not created.
4. The first error in the batch is returned.
5. User cannot fetch information on the batch as it was not created.
**RollbackOnError = False**
1. User creates a batch payment.
2. Batch is error checked.
3. The batch is created, even if it has errors.
4. All the errors are returned.
5. User fetches information on the unconfirmed batch, such as its status and list of errors.
6. User goes to the online bank to confirm the payments that do not have an error.
7. User fetches information on the confirmed batch, along with a list of payments that did not get confirmed due to errors.
8. User fixes the error payments in their accounting system and creates a new batch for those payments.
9. User goes to the online bank to confirm the new batch.
#### RollbackOnError payment process (using “Straight through”)
**The steps below describe the RollbackOnError processes when there are errors present.**
**RollbackOnError = True**
1. User creates a batch payment.
2. Batch is error checked.
3. There are errors present, batch is not created.
4. The first error in the batch is returned.
5. User cannot fetch information on the batch, as it was not created.
**RollbackOnError = False**
1. User creates a batch payment.
2. Batch is error checked.
3. There are errors present.
4. Payments that do not have an error get confirmed, while payments with errors are not confirmed (executed).
5. User fetches information on the confirmed batch, as well as a list of payments that did not get confirmed due to errors.
6. User fixes the error payments in their accounting system and creates a new batch for those payments.
### Fetch receipts for payments
Users can fetch information on a batch by using the *GetPaymentsResult* (6.1) function. If the batch is confirmed, the user will receive information on confirmed payments, as well as a list of payments that could not be confirmed due to an error. If the batch is not confirmed, the user will receive two lists: one of unconfirmed payments that do not have an error and one of unconfirmed payments that have an error.
### Initiate payment without using the online bank to confirm payments
Users can create a single payment (both credit transfers and claim payments) without needing to confirm it in the online bank. To do this, the user creating the payment must be configured as a “straight through” user (see chapter 3.2 and 4.2 for more information). The payment gets confirmed automatically and information on the payment will be returned.
### Future payment batches
Users can create future batch payments by setting the *DateOfForwardPayment* parameter in the *Payments* (6.3) class as a date in the future. If information is fetched on the batch before the date of payment execution, the date of future payment is returned along with other information. It is also possible to see the date of future payment in the online bank.
### Future payments
Users can create future payments by setting the *DateOfForwardPayment* parameter in the *Payment* (6.26.3) class as a date in the future. It is possible to see the date of future payment in the online bank.
### Approval process
If a user that creates a batch is configured to use the online bank approval process, the batch needs to be approved in the online bank. For more details on the approval process, see chapter 4.4. Note that the approval process is only available for batch payments.
### Claims with incurred expenses
If a batch is created that does not need to be confirmed in the online bank (using straight through processing, see chapters 3.2 and 4.2), and the batch includes a claim that has incurred costs such as interest or other costs, the claim will be paid with all the incurred costs. This means that the total amount of the batch payment might be higher than originally anticipated because of the incurred costs of the claims within. If information on the batch is fetched, a breakdown of all the costs for the claims will be retrieved.
If a batch is created that needs to be confirmed in the online bank and it includes a claim that has incurred costs, the updated amount has not been calculated and the batch will get an error if a user tries to confirm it.
When a single claim payment is created and it has incurred costs when it is confirmed, the total amount withdrawn will be higher than the original claim amount. After creating such a payment, information on it is returned immediately, along with a breakdown of all costs.
### Submitting a batch that is visible to all employees
Batches created by the payment service are by default only visible to the person that created them in the online bank. However, if an asterisk (\*) is added to the front of the batch name, then the batch will be visible to all users that have access to the company’s online bank. All of those users will be able to view and confirm the batch in the online bank.